[RELEASE] OpenSource File browser

[maxthebest]

Hi guys,
I've been working on a file browser last summer, and now, it has been finished for quite a while, and I haven't a clue of what I could use it for...
So, I just thought I would release the source code under GPL, so that other people can use it.

Here are the few features that makes it a little more than a basic fil browser:
-It has different themes you can change into the option menu
-The display is made in a Rolodex style presentation, dunno if it means what I mean, but that's basically the same idea as Art used in his xflash (but coded from scratch). So, I like it :)
-Other small stuff you'll discover.

So, for any non developer, this is kind of a useless stuff, because if you run the eboot which is in the zip, you'll have a very nice file browser, but which won't do anything when you select a fle...

So, if you do are a dev, just modify it a little, just adding the action you want to apply to the file selected, or modify it a lot, just remember to release it under gpl too, and to quote the author (myself :))
Of course, It'd be great if anyone using the source coud send a little mail to show me how they used it, I would love that!

Here are is a screenshot of the browser with the default theme more are available on my flickr page.




Don't hesitate to send a mail here: [email protected]
And, visit my web blog

Download Source Code & (useless) Binaries

[Baptiste27]

Sympa max ;)

[maxthebest]

Merci :)

[cory1492]

maxthebest:
Generally this "rolling way" is called a "rolodex" style presentation (if you ask me, and yeah I remember when rolodexes were still the iPhone/pda of the year gizmo.) See here for an example image of a now seemingly ancient (but surprisingly still not hard to find) uber desktop item.

[thecobra]

maxthebest,cool thanks for giving the source code. it may be helpful for some people here.

[maxthebest]

maxthebest:
Generally this "rolling way" is called a "rolodex" style presentation (if you ask me, and yeah I remember when rolodexes were still the iPhone/pda of the year gizmo.) See here for an example image of a now seemingly ancient (but surprisingly still not hard to find) uber desktop item.

Oh! thanks a lot, that's exactly what I meant, post edited :)

maxthebest,cool thanks for giving the source code. it may be helpful for some people here.

You're welcome, I hope it will be useful to someone :)

[_dysfunctional]

A few reasons why I wouldn't use this:

1. There is no modularity. Everything is thrown together into one sourcefile, which, granted, will run out the box and show people how it works. However, there is not sense of being able to copy and paste the code and use it in my own project, which is the point of a library. This would be fine if it was specifically built just to make file browsing easier, but as it stands, this would be one PITA to integrate into my own project.
2. Do not define pspDebugScreenPrintf() to printf(). They are not the same thing. Even concept wise they do not do the same thing. The standard C function printf() is used to print text to the Standard Output, or stdout. pspDebugScreenPrintf(), rather, is used to print debug text to the PSPs screen, in software. Not only is this slow, its name pretty much sums it up. It is part of the pspDebug library, which is used for debugging, and if you are releasing this to the public it should be far away from the beta/debug stage. (Also, no, I understand that you will always be debugging something, but you shouldn't release something that uses a debug library to the public.)
3. Use snprintf() rather than sprintf(). It's safer, and takes just one extra parameter, the length of the buffer so that it does not overrun it.
4. You are using the standard C file IO library in this. This may be good for portability, sure. But on the PSP speed is usually the key and it is MUCH faster to use the native librarys (sceIo*) rather than use the newlib wrappers for them.
5. Holy hell, globals. Get rid of them. They are evil.
6. You aren't using meaningful variable names. How should you expect someone to use this without knowing what the variables 'a', 'IRS', 'file', 'osel, 'fosel', and 'but' do?
7. You should either A) Prefix your functions with a specfic, unique prefix to avoid duplicate function names, or B) Compile with g++ and use a namespace.
8. You have a whole lot of hardcoded nonsense going on in the current selection and printing of the files part of your code, You should go over that and use a loop to improve readability.
9. Try generating the colors manually, so that you aren't limited to the fixed amount of theme options you have there.
10. Declare variables when you need them rather than at the very top of the file so you don't have you continuously scroll up to see which variable is which.
11. DO NOT INCLUDE SOURCE FILES. That's what header files are for. Never, ever, ever, ever #include a .c file. Ever. Ever. Ever. Ever.
12. Use consistant function names. Don't have one function called This_Is_A_Function() and another called ohheythisisalsoafunction( ). Pick one and stick to it, it will improve readability. Consistancy is always good.

Well, good luck with this. I hope you don't take any of the above personally, I'm only trying to help.

[maxthebest]

Well, thanks a lot for all of this, I' taking notes of this...
But, first, it first was a personal project, so, the variables names are very understandable for me, and that's all I cared about.
I is not meant to be any kind of library, it's just a code sample I thought I wuld use, but didn't (yet), and any programer can use this in his text, as the tittle suggests, it's an open source file browser, and not a file browser library.
About the debug stuff, I think that everyone uses the debug library for printing... maybe it's not great, but it works for me... and I don't know any other ways to print text.
About including *.c files, I know it's evil, but well, it was easuer for me, and ... it works, lol
What do you mean by generating manually colors?

Anyways, thanks again, I'll try to remember that, but I have to say, about the variable names and place of declaration: I guess it depends on the programmer's choice, I feel like it's esier to have all the declarations at the same place, so, you know where to look for it.

[Davee]

Globals are slower than local vars.

[yaustar]

Globals are slower than local vars.

Not necessarily but it does help the compiler optimise better at times. There are also some rare cases where using a global over a local variable can make it run faster.

@maxthebest: The advice given is for future reference and to make you a better programmer. Some the advice such as variable naming is more to do with working with other people and making it as easy as possible to work with your code.

[maxthebest]

Yeah, I understand that, and thank all of you very much for that :)
By the way, noob question: what are globals?

[slicer4ever]

max, globals are variables declared at the top of the scope of the program

anyways, globals are not evil when making an damn game, i can understand why their evil in a library, but if your designing a game with a few function's that rely on multiple variables, it's far easier to have a global variable which can be easily accessed from any point in the program, than to have to pass a million parameters though your function

[maxthebest]

OH, okay, thanks.
Yeah, it's sometimes easier, but I'll try to do better next time :)
Thanks again :)

[cory1492]

max, if you're like me you do what works until you find (or are taught, rather than ridiculed into) a better way ;)

A short read that I've found quite helpful and touches on a lot of the previous comments, google for the pdf of:
C & C++ Programming Style Guidelines Fred Richards

[maxthebest]

Okay thanks, I'll check that out ;)

[xart]

globals should never be used in programs, in a library it is ok as you only use a few that you realy need as they are not visable to the software when the library is linked.

that is what you should try and keep to and is what \i try to keep to in my software, too many globals in software can cause major issues as your program grows

[Davee]

globals should never be used in programs, in a library it is ok as you only use a few that you realy need as they are not visable to the software when the library is linked.

that is what you should try and keep to and is what \i try to keep to in my software, too many globals in software can cause major issues as your program grows

Globals sometimes are a great advantage. For example, most of my arrays are global, as more than one function needs to access them.

[yaustar]

Globals sometimes are a great advantage. For example, most of my arrays are global, as more than one function needs to access them.

Ideally, in that case you should pass it as a parameter to the function that needs it.

[thecobra]

Ideally, in that case you should pass it as a parameter to the function that needs it.

yeah that good but like davee i use global for array and some int variable when it used a lot in my program like for example "file browsing". i usually update the array of file every time i search the dir. also when the user execute a file and also like in 4 or more part of my script that i can't remember right now. but passing them as parameter is also good :)

[maxthebest]

okay, I'll try to forget about globals, and try as often as I can not to use them.
Thanks for all those advice!

[Davee]

Ideally, in that case you should pass it as a parameter to the function that needs it.

Yes, I know that, I'm not stupid. Sometimes however, it's just not possible to do that.

[TurtlesPwn]

Yes, I know that, I'm not stupid. Sometimes however, it's just not possible to do that.

Such as?

[Davee]

Such as?

Function hooks...

[TurtlesPwn]

Function hooks aren't commonly used it programs in this sense, but I will agree they are one use for it.

[Davee]

Function hooks aren't commonly used it programs in this sense, but I will agree they are one use for it.

Agreed. I was just trying to justify globals arrays to yaustar ;)

[maxthebest]

Well, I know in some cases it makes it pretty much easier to use globals, because sometimes, you're having troubles passing arrays in parameters (well, I had that kind of problem, dunno why... so I chose the easy way...)

[xart]

Globals should never be used in general and you can write software with zero globals, for libs you never going to make any globals if used accessible so globals in lib can in away be ok to a point.

Any one writing software knows this.
If you need a global you need to think again about your software code structure.

I admit I have used globals myself as we have all done it as it is a lazy and quick and dirty hack out of a issue of recoding stuff but if global is used must be address in some stage of development of the software.

One way you could easly solve your issue is to create a struct then pass it to a function, struct pointers

[Davee]

Globals should never be used in general and you can write software with zero globals, for libs you never going to make any globals if used accessible so globals in lib can in away be ok to a point.

Any one writing software knows this.
If you need a global you need to think again about your software code structure.

I admit I have used globals myself as we have all done it as it is a lazy and quick and dirty hack out of a issue of recoding stuff but if global is used must be address in some stage of development of the software.

One way you could easly solve your issue is to create a struct then pass it to a function, struct pointers

Once again, function hooks usually require a global. Since you cannot pass vars through.

For example if you need to check a certain file is opened. You would record the return SceUID into a global. Then when it comes to reading the file you would compare the passed SceUID with the one in the global.

[_dysfunctional]

That is almost completely PSP specific, I doubt he'll be doing anything like that on any other platform.

[Davee]

That is almost completely PSP specific, I doubt he'll be doing anything like that on any other platform.

Obviously...

This is the PSP Development section afterall ;)