Applications and the Difficulties of Portability? 145
insane_coder asks: "I'm a software developer who writes a lot of freeware utilities in C/C++ which are all cross platform and work well. Lately some of my users have been pestering me to stop wasting precious development time supporting minority OSs like Linux, and get more work done for the majority — the Windows users. Now all of my utilities are simple tools that perform various operations on files such as compression or rearranging. I've also made a few frontends for them using the excellent Qt library to allow the user to select a file and process using a simple GUI. In the dozens of applications I wrote, most of them several thousand lines long, I haven't written a single conditional for any particular OS. When I release, I just compile each app for all the OSs I have access to and post them on my website. I barely expend any effort at all to achieve portability. So the question I have to ask is: Why do the masses perceive portability as something that requires effort and a waste of time?"
"Most applications don't do anything fancy or need to talk to devices and therefor there is no need to do anything special other than compile them on a particular OS to run on that OS. So why are there so many simple apps using native APIs to do simple things like file reading instead of the standard ones? Why are we projecting an image that one must go out of their way or switch to a different language in order to achieve portability?"
It's Windows development tools (Score:5, Insightful)
It's the Windows development tools. By default they generate code that uses tons of Windows-specific APIs that aren't portable to anything but another version of Windows (and sometimes not even then). If you start with OS-specific code, then yes supporting other OSes looks difficult. Combine this with Microsoft's business need to make portability look as difficult as possible to discourage developers from aiming for it and the results are predictable.
Re: (Score:2)
Re: (Score:1)
Re: (Score:2, Informative)
Re: (Score:2)
But if you're writing POSIX code for portability purposes, why would you be using native Win32 functions?
Re: (Score:2)
You wouldn't, but, AFAIK, it works the other way around, too: the win32 functions won't interact with your software, either. E.g. no communication between win32 and POSIX processes. I'm not even sure POSIX processes show up in the Windows process manager (I've been told they don't, but I haven't ever verified that).
Re: (Score:3, Informative)
It's Posix-compliant at the most minimal level. When Microsoft designed the subsystem, it had one goal: be able to check off the "Posix compliant" item on the government purchasing checklist. It did not want Posix apps developed, because that would be against Microsoft's business interests, but it needed that compliance to technically qualify for government contracts. So it implemented the absolute minimum it had to to get the minimal certification and no more. And minimal Posix compliance is minimal indeed
Re:It's Windows development tools (Score:5, Interesting)
And these people are not necessarily your average fresh-out-of-school programmer. Sometimes even people with several years of experience fall into this category and refuse to work on cross-platform code because they say "it consumes more resources". An example I have dealt with recently is Garage Games and their Torque line of products.
Garage Games makes game engines and they used to announce on their website that their game engines run on Windows, OS X and Linux. Long story short, the Linux version is far from the quality of the Windows and OS X counterparts (when it runs at all) and the company dropped Linux as a supported platform, "because it consumes too many of their resources". Instead, the Linux version is now supported by the community - but it bears the same price tag, nonetheless...
Re: (Score:3, Insightful)
There are levels of portability and I wouldn't especially call code written for Windows, linux , osx/bsd "portable". Personally I think that portability has a natural tendency to emerge from already well written code. Most of what you call not portable is _downright stupid_ generally. Well, in most cases. Portability is
Re: (Score:2, Informative)
Re:It's Windows development tools (Score:5, Interesting)
Amen.
I write only portable code (currently very happy with wxWidgets, and have used Qt in the past) but MS fud is so thick that I have at times had to convince clients that using platform-neutral code would be faster than an "all Microsoft solution."
I've also encountered an amazing number of developers who have no real interest in writing good software. They simply want to do things the easiest way possible that requires the least thought, and MS caters to those people and always has.
There is a delightlful ancedote told in a book by one of the guys who was deeply involved in the first Visual C++ release (the old C7.) At the time Borland owned the C++ compiler market on Windows, and MS was playing catch-up big time. The marketing people realized that the technical goodness and standards-conformance of the Borland compiler was only of interest to a small core of die-hard techies. The much larger market was C programmers who wanted to be able to call themselves C++ programmers. Thus were the Visual C wizards born. They made it easy for people who had no clue to create "classes" and pretend to get it (while putting everything into a single procedural method.) I wish I could recall the name of the book--it was one of the most unselfconsiously arrogant memoirs I have ever read.
One response to the false belief that cross-platform code is not cheaper than single-platform code is to make the point that writing cross-platform code is quite different from porting code from one platform to another. Another is to remind people that we are dealing with Turing complete machines, so all functionality is always available on all platforms. This isn't actually relevant, but it will shut people up who don't know what they're taking about, and if we have anything to learn from MS it is that substance and quality mean nothing when put alongside a catchy argument.
Re: (Score:3, Interesting)
Re: (Score:3, Informative)
Re: (Score:3)
Re: (Score:2, Interesting)
I wrote some complex GUI code with Qt, and found it much easier than any APIs I saw for Windows. From what I've seen, it requires less work to use Qt.
Overall I see Win32 API is just complex. I once was reading up on MSDN about how one would go about processing stdout from a child application. They presented like a 50 lines solution using many tricky looking calls. I ended up writing functionily identical code using POSIX functions like dup2() and fileno() (which Windows in fact does support right out of t
Re: (Score:2)
But once extended, they stay extended. Qt has been there for a while, wxWidgets is there for a vast array of applications. I personally hate dockable floating toolbars, and the apps I write do not require them, so I haven't felt your pain there, but the improvement in cross-platform toolkits in the past five years has been enormous. Even as I write this there is someone thinking
Re: (Score:3, Informative)
I remember that story quite vividly as well: "When doing market research, we realized that mediocre people didn't want a real C++ compiler, they just wanted C++ on the box and *.cpp file extensions so they could bill themselves out ($$$) as C++ programmers. We then spent the next 5 years fixing all of our dork-isms in the C++ compiler to bring it up to standards, but that didn't matter because we had already crushed our competition by making flashy
Portability Isn't Hard (Score:5, Informative)
- Sockets (BSD sockets vs. Winsock's almost-compatible variant); this is not a problem in most higher level languages
- GUIs (there isn't really a standard; perhaps wxWidgets?)
- Threads (POSIX threads vs. whatever Windows has)
- Processes (fork, AFAIK, really doesn't exist on Windows)
If I need any functionality that isn't readily portable, I usually target POSIX or BSD, which makes my code portable to many *nix variants, and Windows using Cygwin.
Of course, there are also a whole bunch of cross-platform libraries out there, like glib, the APR, SDL, Qt,
Re: (Score:2)
I made the mistake of choosing GTK+ for my application [sf.net]. Only after a while did I realize that GTK+ doesn't run natively on OSX. If I had to do it all over again, I'd probably choose Qt.
If you're using Java, Swing is usually a pretty safe bet
Re: (Score:2)
There's no possible standard way to produce a GUI that "works right" (i.e. how Joe Ordinary User expects on each platform) portably across all platforms. The problem is that different platforms have thoroughly different UI metaphors for things like modal vs. non-modal dialogs and stuff like that. Make your app work right on one platform and it will clunk on another. Your best choice is probably to de
Re: (Score:2, Insightful)
This is a big problem, and I think it is because many toolkits don't have generic functions. They require a developer to specify pixel locations, font sizes, or similarly low level things.
A toolkit should ask for generic information and format it in the proper way for a given OS. You should not be indicating toolbars, menus and widgets. You should only need to specify what functions are made available and the name, icon, etc associated with them, the toolkit should put these into menus, toolbars, or whate
Re:Portability Isn't Hard (Score:5, Informative)
I think you've identified on most of the major areas that cause portability problems, with the possible exception of endianness. Since I actively maintain software under Windows, Linux and Solaris, let me add some comments:
If you're developing a GUI application then a decent GUI library will handle most of your problems. Libraries like wxWidgets and QT provide cross-platform GUI widgets as well as thread creation and synchronization primitives. They usually also provide socket abstractions, or you can use another cross-platform library like ACE.
Things get more hairy when you enter the realm of server applications and high performance. Software written for *nix is pretty much straightforwardly portable to Windows, but not the reverse.
The difference is in the schedulers, which affects processes, threads, synchronization, and blocking and non-blocking IO. In a nutshell the Windows scheduler deals with threads and not processes, is a fair scheduler, and a thread can block on multiple conditions simultaneously.
That should be a lot to digest, so let me try to explain that statement and its implications:
First a disclaimer: I am going to talk about *nix in generalisations, because both Linux and Solaris support a variety of schedulers and the default scheduler can change between versions, and userland and kernel threading libraries behave very differently.
ONE: The Windows scheduler schedules threads. Processes are merely containers for threads and their address space, access tokens, etc. Processes are not scheduled. This means that a multithreaded process on Windows has fundamentally different time sharing characteristics to a *nix application. The characteristics would be most similar to a multiprocess application in the *nix world. Most *nix schedulers I have encountered schedule processes first, then schedule threads within the process.
TWO: The Windows scheduler is "fair" -- it is a multilevel queue with round-robin at each level. Threads with a higher priority will always preempt those of a lower priority, and priority elevation is used to prevent starvation.
A number of *nix schedulers use a n adaptive algorithm that favours historically busy processes. This means that a producer-consumer approach may work well on a Windows system, but experience high latency on *nix (note: not reduced throughput under load, but increased latency). Such an approach can work on *nix, but must be implemented differently.
Both Linux and Solaris can be set to use round-robin schedulers (e.g. Solaris's real-time class process), but this can degrade overall system performance.
THREE: A thread can block on multiple objects simultaneously. I said "conditions" before, but I'd prefer to get more specific. A Windows thread can wait for the end of another thread or process, a mutex, and event (like a condition in *nix), an IO operation, a semaphore, a timer, and a couple of others. The thread can also block under any one, or all, of a number of objects are in the signalled state.
Compare that to *nix where you can wait on one of anything except for IO, where you can use select (or poll or dev/poll or kqueue) to wait on multiple non-blocking file descriptors. kqueue is a little more functional, but to my knowledge still doesn't support synchronization objects. If you are using SysV semaphores you can wait for multiple semaphores to be signalled.
This has huge implications for application design. On Windows you can have a consumer thread wait on multiple producer threads using one mutex per consumer to control synchronization. All threads can be awoken from any wait state by a global event to inform them of reconfiguration, shutdown, etc. This is quite trivial, and is a straightforward and easily understood design.
Move the same design to a *nix platform and you have problems. First your consumer thread can't wait on multiple producers without some radical changes (use could pipes rather tha
Re: (Score:2)
I always make sure my code is endianness-clean. I have big-endian and little-endian systems at home. Same goes for word size, although I occasionally write code that requires a 32-bit system, and I don't always support sizes other than 32 and 64 bits.
Re: (Score:2)
Item One is actually wrong, as far as Linux is concerned at least and likely most other Unixes aside from Sun. On Linux and most of the *BSDs, threads are processes at the kernel level. The only thing special about them is that all the threads in a "process" happen to share address space, file descriptors and a bunch of other things. The schedule doesn't care about all that, though, to it a process with 12 threads is simply 12 processes to schedule, each with it's own priority and other scheduling character
Re: (Score:2)
I got that from the way the earliest versions of the fork() function worked when I began programming on Unixes (specificially 2.1BSD, although we quickly upgraded to 2.3BSD).
Re: (Score:2, Interesting)
I supposed you were just mixing up vague recollections about vfork()
and its limitations (sharing address space until execve(), etc) with
vague recollections about copy-on-write pages in the child & stuff,
and you were just confused by the whole thing.
But no, you're deliberately spreading misinformation and don't
care about that --
Is it so humiliating to admit you're wrong ?
Re: (Score:2)
Having never used AIO, if what you say is true, I'm sorry to say I expected more...
Re: (Score:2)
The Event objects are always problematic; see: boost's rationale for not using events [boost.org].
And there is no nice way to use the window's primitives to create a multiple-reader / single writer semaphore, like there is with the posix threads
A better question (Score:2)
Re: (Score:1)
>If they won't believe or accept your response when you tell them how little effort portability requires, why should you care about their false perceptions?
It is annoying that users bring it up over and over again despite myself telling them there is no effort involved.
I'm also concerned with the programming community as a whole that we're somehow projecting an image that portability is just too hard.
>For instance, is it a concern that others will believe the non-programmer over you and make d
Re: (Score:2)
Re: (Score:2)
As mentioned previously, create a FAQ entry - and include links to sites known to host cross-platform projects (such as Sourceforge, Freshmeat, etc.) or major cross-platform applications (e.g. Firefox).
Portability is not hard, nor is there such a projection taki
Users expect computers to be hard (Score:2)
The problem is, people expect computers to be hard. They expect that there is some knowledge that they should be looking for. Some users look for solutions to their problems on Google before (and often instead) checking the documentation. And then they write bugreports to the author and describe how their tried to avoid problems in long forgotten versions of the software b
Re: (Score:2)
Because a lot of the time it's true (Score:2)
. When heavily optimizing, you will need to make different tradeoffs on different architectures. So while a lot of time it's not a big deal, like for games, for some applications, like firewalls, porting will involve a lot of reading the fine manual.
Re: (Score:2)
Re: (Score:1)
Re: (Score:2)
Ugliness? (Score:3, Interesting)
Most people, when they run an application on Windows, expect it to react in the same old Windows way. Many of cross-platform libraries do a poor job of doing that. I personally don't use GAIM because I can't stand the way it looks. Even though complaining about the ugliness of the GUI might seem stupid to some, it is a genuine problem with people. Clearly, it makes some form of different, as evidenced by the ever increasing "beautification" of window managers like KDE and Gnome.
It may be that this bugs me more than most precisely because I am a developer. It may be that it bugs ordinary people even more. I have no idea. But I think that increasingly the transparency of external libraries would probably help gain them acceptance. The problem is made even worse by libraries that clutter up your system by popping up and asking you to update, or add entries in your menus that you'll never need, as a user.
Java propaganda (Score:2, Insightful)
Because all they teach in schools now is java. They have all bought into Sun's propaganda. The students don't know any better and believe what they are told.
You are absolutely correct in your approach, well written C/C++ code will compile and run on just about any modern OS and results in the most efficient and fastest applications.
Another reply above also makes a good point that t
Re: (Score:3, Insightful)
You pose an excellent, yet rhetorical question and it illustrates perfectly the absurd redundancy of java which claims to be cross platform but really is not, all it does is waste system resources and ecourage you to depend on inefficient and probably broken classes written by other people.
Where did this rant come from? The o.p. didn't mention or allude to Java at all.. it was a question about why people think that cross-platform development effort is hard/useless.
Are you saying that people only thin
Re: (Score:1)
If your goal is to teach students the concepts of object oriented programming, Java is a great choice. Last time I checked, the goal of CS isn't simply to teach specific programming languages and technologies. The aim is to teach students the important concepts they'll need to be sucessful in the field.
Once you learn how to program, you can learn to do it any language.
Re: (Score:2)
Your parent poster was claiming that people think cross-platform development is hard/useless because Java marketing says "Cross-platform development is hard/useless, unless you use Java!" and lots of people (especially those who have only ever used Java) believe them.
Re: (Score:2)
You know what? You're right. I'm writing my next app in hand-coded binary, written in my own hex editor, just so I don't have to depend on anybody else's code.
</sarcasm>
I agree in part -- don't depend on libraries you can't control. But do depend on libraries to which you can get the source code -- that way, if there's a problem, you can fix it, and if there's no problem, you just saved yourself a whole shitload of work.
And by the wa
Re: (Score:2, Insightful)
I wouldn't blame it solely on Java. Some of it may be that some C++ programming classes today won't even teach the standard file manipulation libraries such as fopen() or std::fstream, but instead teach Win32 API method to open a file.
Regarding 3rd party libaries, depending on some of them is actually a good idea. The zlib library for example is indispensible, hence why almost everything uses it.
As for what Java zealots tell me, just yesterday someone mentioned to me I should switch all my C++ apps o
Re: (Score:1)
Ignore naysaying insects (Score:2, Insightful)
The bottom line is that around 99.9% of human beings are small minded, brainless insects who are utterly devoid of intelligence, initiative, self-responsibility, creativity, or vision, and who in general terms don't really have any terribly concrete reason to exist. The one thing
Re:Ignore naysaying insects (Score:4, Interesting)
Re: (Score:2)
I see. Do you actually give any thought to how the people who write free software support themselves? I remember when Patrick Volkerding mentioned his illness here a while back...people seemed to spend more time calling him an idiot and accusing him of faking than anythin
It depends. (Score:5, Insightful)
Other environments (usualy very customer centric ones, let say consulting firms, with strict deadlines, marketing getting in the way, etc) and more complex applications with very specific needs, it becomes trickier. These are the environments where your job is hard even if you're only supporting one platform, and even using every single last specialised API the platform offers still let you wish for more. In those cases it becomes a bit more annoying to have to go with the lowest common denominator.
Then add to that that users of different platforms -expect- different things. It isn't the end of the world to make something that works on both OSX and Windows, for example. But users of both platforms expect certain different things. I don't know the status right now
And last, but the most important one, testing, QA, etc. Doing cross platform, no matter what you do (unless you only do HTML and target Firefox only or something) means testing on those platforms, if only to look. That means moving the files, booting up the virtual machine, or something, to check it out. If the app is remotly complex, that IS time consuming like hell.
So in the end, it really depends. If you release your app to the general public, then the advantages of cross platform often outweight the "cost", and its only a matter of time before we are -expected- to do it. When your audience is more limited though, you often benifit more from targeting one particular platform and optimising your workflow like crazy for it, the time saving is significant.
third party interfaces (Score:2, Insightful)
So stop supporting the minority users! (Score:4, Insightful)
Alternately, here's a money-making opportunity... "Whichever platform raises the most money by $DATE will be the one that's supported"
Qt? For freeware? (Score:2)
Re: (Score:1)
Ignore most of the replies (Score:3, Insightful)
handheld? (Score:1)
Does this apply to handheld devices as well?
Re:Ignore most of the replies (Score:4, Funny)
Re: (Score:2)
Portability has advantages, too (Score:3, Interesting)
Re: (Score:2)
Re: (Score:2)
Reposting, formatted properly (Score:3, Informative)
Basically, some people will say things like "Portability issues only happpen on Windows because of the use of Windows specific API.... and Linux somehow magically escapes this problem."
I'm sure you are already aware that it is not true, because your code is portable and uses readily available libraries that do not vary
Ok, now the actual reply: (Score:3, Insightful)
Linux does not magically escape the problem. However, Linux developers are much more likely to write portable apps, because they remember how much it sucks to have their OS be unsupported, so they will naturally want to support BSD and OS X also.
POSIX does help, however. NT was originally going to claim POSIX compliance, bu
Re: (Score:2)
Thank you to whoever reformatted my post for me. I really appreciate it.
Wrong on pretty much every account here, at least in theory:
* An API is not necessarily more stable than a config file schema.
* You could just as easily use some sort of API on Linux, or a config file schema (.INI files, anyone?) on Windows.
* It's not only possible, but often easy, to implement some sort of API that uses config files as a backend. That's basically how
Re: (Score:2)
I wouldn't necessarily agree with that. As I said, a file format is not necessarily less stable than an API.
For instance, /etc/passwd is not likely to change. It's stable enough and abstract enough that you would not build an API around it merely to protect yourself, should the format change, because if your API is low-level enough that it's even a question, a forma
Re: (Score:2)
Re: (Score:2)
I seem to remember a mailserver, Exim, which checked the mtime on its config file on every message received, and reloaded the data on config file change. More modern systems could easily check the file with inotify, thus responding immediately to any change, and I believe vim (and likely other text editors as well) creates a new file, then over
Re: (Score:1)
The code will have to call system functions sooner or later, portable or not. The point of many libraries out there is providing a standard interface to those functions (while the code in the libraries may vary between platforms to account for those differences).
Re: (Score:2)
I for one welcome my "Crazy Optimization OverLords"
Really though, only about 6% of code is non-portable code. Those optimizations are usually a big deal for those systems, and rewriting 6% of your code if you new what you were doing in the first place, is not going to be that big of a deal.
Fuck them. (Score:1)
Fuck them. You're providing them with programs for free. Just because one platform has a majority of users shouldn't mean it gets all the attention.
If you were making a LIVING off of the products you produce, doing the opposite would be probably be the wisest course of action.
Cross-platform is hard (Score:2)
But Trolltech did all the work for you. They make it easy.
Anybody who has never experienced that may not believe it. Trolltech is hiding a lot from you. (This is a good thing.)
Hah! I have yet to see a decent port to MacOS (Score:4, Informative)
The reason cross-platform is hard is because GUIs behave very differently from each other. To be a "correct" Mac OS program, you must support:
1) AppleScript, at least the bare minimum actions.
2) The Services menu. Many ported apps don't have it.
3) The integrated spell checker. Most ported apps don't have it. Including biggies like Microsoft Office. (Needless-to-say, Firefox also doesn't support the integrated spell checker.)
4) Verb dialog boxes. That is, no "yes/no" questions in dialogs, they must all be "Save" "Don't Save" (or similar.) In addition, the location of Ok and Cancel are different in different OSes.
5) Drag&Drop, another simple feature the majority of ported apps get wrong. (Note: this includes drag&drop text editing as well as dragging snippets to the desktop.)
6) Mac-like edit boxes. Here's an example ported apps almost always get wrong: if your cursor is at the bottom line, but in the middle of the text, and you hit the down arrow the cursor should move to the end of the bottom line. On Windows, it should do nothing. On Linux... well I have no clue if Linux has any standards for arrow behavior in edit boxes. (Firefox gets this wrong also, as do many, many apps.)
7) Standard Mac menu shortcuts. This is pretty easy since other OSes ripped-off most of Apple's shortcuts anyway.
8) Being responsive to sleep, hibernate and shut down requests from the OS. Every time I see OS X telling me that shutdown was cancelled because of some mis-behaving app I want to scream.
9) Not relying on any absolute paths other than those defined by the OS. Lot of apps get this wrong.
10) Using Apple's color picker, font picker, "Special Characters" picker, etc instead of your own. Many apps get this wrong.
I'm probably missing items on this list. In addition, Windows has items on its list different from the Macintosh list. (For instance, coping with Active Directory, having an installer.)
I can guarantee that your cross-platform framework gets at most half of these things right. The Java VM gets basically none of them right. Firefox gets like 3 of them right. The reason you think cross-platform development is easy is one or more of the following:
1) You don't bother to QA your product on Mac/Windows/whatever. (This is the most likely.)
2) Your programs have trivial GUIs and/or you don't give a whit about the quality of the GUI.
3) Your programs are CLIs and have no GUI at all. (Note that if this is the case, they're still probably wrong on DOS, which is quite different from Unix CLIs.)
Tell you what, the instant I see a single ported app to Mac OS X that actually looks and behaves like an OS X app, I'll eat my words and agree with you. But I don't think that'll happen.
Re: (Score:2)
11) Using Apple's save and open dialog boxes that correctly remember recently accessed folders and let you drag in files.
12) Having the green window-optimizing button correctly adapt the window to the size of the document.
13) Allowing re-arrangable and customizable toolbars.
14) Not requiring the right-click for essential functionality.
15) Drag-and-drop program installation and removal.
Adobe applications
Re: (Score:2)
Re: (Score:2)
"Run more or less the same" doesn't mean "not following the OS user interface conventions".
The details of the user interface, like how edit boxes work or what input panes or panels are used, are not going to stymie users. The things that piss users off are changes in the layout or missing elements on one OS or another. You
Re: (Score:2)
Re: (Score:2)
How about this argument:
1. Apple supplies the Java VM on Mac OS X (true)
2. The Java VM doesn't follow your list of properties
3. Therefore, either:
a) Apple disagrees with you about what a "correct" Mac OS program should be
b) Apple is incompetent and _should_ fix their Java VM to behave properly
Neither of these conclusions say I, as a de
Re: (Score:2)
(Look at Finder alone-- it used to be the model of how to build a file browser, now it's a piece of crap that can't even cope with making image previews or connecting to network drives. Thanks, Apple, I love it when my iBook freezes because I had the gall to close the lid while it was connected to a network d
Re: (Score:2)
Re: (Score:2)
nf FAQ for Mac:
Q. I set NSRT location to "Frontend Directory", but where is it?
A. nf.app/Contents/MacOS. Put nsrt into this folder.
Q. I set Start location to "Frontend Directory", but it doesn't work.
A. Qt rejects to show the contents of the nf.app when starting. Use other locations instead.
Q. Where is the preference file?
A. In nf.app/Contents/MacOS.
Q. Where should I put the lang folder?
A. In the same place as nf.app.
Q. What is the blank rectangle above "HTML" radi
Re: (Score:2)
For those just joining us, we're talking about this Read Me file:
nf FAQ for Mac:
Q. I set NSRT location to "Frontend Directory", but where is it?
A. nf.app/Contents/MacOS. Put nsrt into this folder.
Q. I set Start location to "Frontend Directory", but it doesn't work.
A. Qt rejects to show the contents of the nf.app when starting. Use other locations instead.
Q. Where is the preference file?
A. In nf.app/Contents/MacOS.
Q. Where should I put
Re: (Score:2)
The path for preferences in Windows should be:
$HOME/Application Support/|Application Name|
The two Abouts should be:
About |GUI Front-end Name|
And
About |CLI Tool Name|
And seriously, Slashcode coders, how hard is it to write a regex to determine that "Less Than GUI Front-end Name Greater Than" isn't a HTML tag? Criminy.
Re: (Score:2)
Re: (Score:2)
I believe you'll get better numbers on relative demand when people find it easier and more convenient to choose a platform. Right now, you get situations similar to, "Well
beacuse there are a massive.. (Score:2)
Actually I don't think to many people realize that QT is probably more portable than javascript.
Re: (Score:2)
Cross-platform aids in code quality (Score:2)
Re: (Score:2)
On the other hand, if the same bug shows up across the ports of the package, it is a pretty safe bet to say the bug is in the code and not the compiler or OS. I had an experience recently using an app that was running on Solaris and OS X, getting sporadic crashes on both platforms and sure enough it was a very subtle bog (a number very close to one was being rounded to one).
You linked to ZSNES? (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Testing (Score:3, Insightful)
"Stop porting to Linux?" (Score:2)
Hm, there are no stupid questions ... (Score:2)
Why do the masses perceive portability as something that requires effort and a waste of time?
Because:
I've also made a few frontends for them using the excellent Qt library
Most programmers only profram for ONE platform. If its Windows they use windows APIs, even for somewthing so simple like opening a file they don't use fopen but OpenFile
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
No, only knowledge and willingness! (Score:2)
That's not true, it's quite easy if one knows how. Just visit wyoGuide (http://wyoguide.sf.net/ [sf.net]) and learn how an application gets a fitting native look ("Look
O. Wyss
Re: (Score:2)