Moderator
Tweet
KDE:
1. Find semi-successful open source app
2. Convince yourself that writing C++ is the ultimate form of masturbation, and that learning Qt is better than spending time with your ****************friend, because it's so beautiful
3. Remind yourself why MOC doesn't suck.
4. Take the name of the app, sed /[cg]/k/, check that you didn't end up with three k's in a row. If there are no k's, stick a k on the front.
5. Think of every user-facing function your app could provide
6. Foreach function: create an abstraction layer that supports at least 3 other backends poorly
7. Foreach function: create toolbar button
8. Foreach function: create menu item
9. Make sure it has split windows and tabbing and support for KParts. If you can't figure out a UI, just mimic a Windows one.
10. Make sure it uses Phonon, and KAddressBook. And a dockable Terminal.
11. NEVER use a library with a g in the name. EVER.
12. Publish on KDE-Look.org
13. Promise everyone that you're going to port to Windows, then don't
14. Once every few years, use your toolkit rev'ing as an excuse to start over from scratch.
GNOME:
* Find some reasonable app from another platform (Windows, Mac, KDE, whatever, but preferably, Mac). Bonus points if there are already 3 other gtk-based alternatives who don't want to integrate with Gnome.
* You MUST have a g somewhere in the gname. Extra credit if you can make it a "gn". If you can use "gnu" or "gno" or "gna" you're are gnawesome, and your app is already worth using. Make sure the name of your app bears no relevance to what it actually does. Also, NEVER document if the g is pronounced with the hard-g sound.
* Use at least two object frameworks. Three is even better. I mean the "O" in Gnome stands for object, after all. Take your pick from Corba/Orbit/Bonobo/D-bus. Make sure at least one of them works over the network, but make sure your app never actually uses it over the network.
* Remind yourself that OO in C is not so bad. assert(gtk_no_really_its_not_so_bad). Also, remind yourself that GTK+ is way better than Qt because it has no commercial company writing code for it. So, you know, it's more free, or something, and it's got a + in the name.
* Generate wrappers for every conceivable language, but make sure none of them work exactly how you want. Inisist that your distros package each wrapper in a separate package.
* Explain to at least three other programmers how glib doesn't really have much to do with gnome. Because they care.
* Don't forget a Tango Icon!
* Make sure your app builds on windows, but looks like ASS.
* Enumerate all the features you want your app to have.
* Cut 90% of them. Because they're hard to do. But tell everyone that they don't actually need that feature.
* Implement 2% of them. Hide the other 8% in gconf. Hide them well.
* Your interface must not have more than 4 buttons.
* Make sure it depends on at least four other libraries with g's in their name. That raises your apps' gnomyness
* Don't use Mono, because you are spreading your STD's to everyone. No, wait, use Mono, because it will make you way insanely more productive. Wait, no, don't use Mono, because if you do, some freetard distro that nobody uses won't distribute your app.
* Depend on a module that is "heading toward planned deprecation" so that it will now be "at the end of the Obama presidency we will almost have consensus of heading toward a planned deprecation over 20 years."
* Ressure yourself that even if your app sucks, at least it follows the HIG.
1. Find semi-successful open source app
2. Convince yourself that writing C++ is the ultimate form of masturbation, and that learning Qt is better than spending time with your ****************friend, because it's so beautiful
3. Remind yourself why MOC doesn't suck.
4. Take the name of the app, sed /[cg]/k/, check that you didn't end up with three k's in a row. If there are no k's, stick a k on the front.
5. Think of every user-facing function your app could provide
6. Foreach function: create an abstraction layer that supports at least 3 other backends poorly
7. Foreach function: create toolbar button
8. Foreach function: create menu item
9. Make sure it has split windows and tabbing and support for KParts. If you can't figure out a UI, just mimic a Windows one.
10. Make sure it uses Phonon, and KAddressBook. And a dockable Terminal.
11. NEVER use a library with a g in the name. EVER.
12. Publish on KDE-Look.org
13. Promise everyone that you're going to port to Windows, then don't
14. Once every few years, use your toolkit rev'ing as an excuse to start over from scratch.
GNOME:
* Find some reasonable app from another platform (Windows, Mac, KDE, whatever, but preferably, Mac). Bonus points if there are already 3 other gtk-based alternatives who don't want to integrate with Gnome.
* You MUST have a g somewhere in the gname. Extra credit if you can make it a "gn". If you can use "gnu" or "gno" or "gna" you're are gnawesome, and your app is already worth using. Make sure the name of your app bears no relevance to what it actually does. Also, NEVER document if the g is pronounced with the hard-g sound.
* Use at least two object frameworks. Three is even better. I mean the "O" in Gnome stands for object, after all. Take your pick from Corba/Orbit/Bonobo/D-bus. Make sure at least one of them works over the network, but make sure your app never actually uses it over the network.
* Remind yourself that OO in C is not so bad. assert(gtk_no_really_its_not_so_bad). Also, remind yourself that GTK+ is way better than Qt because it has no commercial company writing code for it. So, you know, it's more free, or something, and it's got a + in the name.
* Generate wrappers for every conceivable language, but make sure none of them work exactly how you want. Inisist that your distros package each wrapper in a separate package.
* Explain to at least three other programmers how glib doesn't really have much to do with gnome. Because they care.
* Don't forget a Tango Icon!
* Make sure your app builds on windows, but looks like ASS.
* Enumerate all the features you want your app to have.
* Cut 90% of them. Because they're hard to do. But tell everyone that they don't actually need that feature.
* Implement 2% of them. Hide the other 8% in gconf. Hide them well.
* Your interface must not have more than 4 buttons.
* Make sure it depends on at least four other libraries with g's in their name. That raises your apps' gnomyness
* Don't use Mono, because you are spreading your STD's to everyone. No, wait, use Mono, because it will make you way insanely more productive. Wait, no, don't use Mono, because if you do, some freetard distro that nobody uses won't distribute your app.
* Depend on a module that is "heading toward planned deprecation" so that it will now be "at the end of the Obama presidency we will almost have consensus of heading toward a planned deprecation over 20 years."
* Ressure yourself that even if your app sucks, at least it follows the HIG.
Kommentar