As of 2016-02-26, there will be no more posts for this blog. s/blog/pba/
Showing posts with label GNOME. Show all posts

The title of this post doesn't mean anything for real.

About a week ago, someone posted Merging: udev and systemd about Udev and systemd to merge. I don't really care about this merge because:

After udev is merged into the systemd tree you can still build it for usage outside of systemd systems, and we will support these builds officially.

There is no need for me to concern about this, even though there were some stirring discussions over this. As long as I don't need to do extra configuration, then I am okay with it. The only drawback is the tarball will be bigger, don't know how big it would be, never use systemd before and I have no need. But if this will make the development easier, then I won't fuss over it.

One comment on LWN.net mentioned Zawinski's Law:

Zawinski's Law of Software Envelopment (also known as Zawinski's Law) relates the pressure of popularity to the phenomenon of software bloat:
Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can.
Examples of the law in action include Emacs, MATLAB, Mozilla and Opera.

This law is attributed to Jamie Zawinski, who popularized it. It may have been inspired by the humorous Law of Software Development and Envelopment at MIT, which was posted on Usenet in 1989 by Greg Kuperberg, who wrote:
Every program in development at MIT expands until it can read mail.

I found this is pretty amusing and somewhat true, but can MATLAB really read mail? Well, not directly, but you can sendmail for sure. I don't feel surprised when I saw Emacs in the list, though I don't really know if it can read mail or not. But once a while, I would stumble across stuff about the bloat of it.

Two replies mentioned about GNOME5 and The Registry, quite sure it was meant to mock around Windows Registry. They are just for laughter, nothing really serious about it, but that doesn't mean they are not true.

But this comment referred to the future of GNOME did cause me thinking:

For Debian perhaps. However, I don't think this is true for GNOME. The future of GNOME is as a Linux based OS. It is harmful to pretend that you are writing the OS core to work on any number of different kernels, user space subsystem combinations, and core libraries. That said, there may be value in defining an application development platform or SDK that exposes higher level, more consistent, and coherent API. But that is a separate issue from how we write core GNOME components like the System Settings.

It is free software and people are free to port GNOME to any other architecture or try to exchange kernels or whatever. But that is silly for us to worry about.

Kernels just aren't that interesting. Linux isn't an OS. Now it is our job to try to build one - finally. Let's do it.

I think the time has come for GNOME to embrace Linux a bit more boldly.

Some people would have strong concern about it if this is real future of GNOME, especially people who use GNOME and already think GNOME is a colossal environment . Some may like the way it goes as becoming an OS, some may think it should not go that way.

I like the way current Linux is. Yes, things are broken sometimes and you may need to put efforts in it if you really care about. Things are pretty complicated, but by having such goal, can you be sure you won't become another same Linux problem which you think Linux currently is having?

You write code which you think they should be in OS core and bring up the issue across different layers of coding. If you look from another perspective, maybe that's because you shouldn't do things that requires such code? I think this somehow resonates with Zawinski's Law. You program expands to where it shouldn't be to. You definitely know you shouldn't, but you still go there anyway.

I stopped using GNOME for at least three years, it had too many stuff I don't need and don't even know they were sitting in my system. I am not entirely sure what it really is, still a Desktop Environment? Same thought goes to KDE, I think KDE could be even bigger than GNOME.

If GNOME evolves into an OS, I won't object it, but they can't be associated with the name "Linux" at all, even it includes Linux kernel within. It would be a new OS, no way you should call it Linux. It's not Linux, it would've gone from Linux road. Not even a Linux distribution, that GNOME will not be qualified for being titled with "Linux" or "Distribution."

Desktop Environment (DE) is a loose term, you can define it with almost everything included or almost nothing, possibly boiling down to just a Window Manager (WM). In fact, you can even argue what should be in a WM. DE and WM would grow as other programs do, that's one of reason that I switched to DWM. Occasionally, people fork DWM and try to make more smaller version of it. I guess DWM is still too bloated for some.

The true issue I have with GNOME is dependency. Even I don't have GNOME installed, I still have a few packages installed inevitably:
~ $ eix -I gnome --compact
[I] dev-cpp/libgnomecanvasmm (2.26.0(2.6)@10/27/2011): C++ bindings for libgnomecanvas
[U] gnome-base/gnome-common (2.28.0(3)@05/05/2010 -> 3.1.0(3)): Common files for development of Gnome packages
[I] gnome-base/gnome-mime-data (2.18.0@10/18/2009): MIME data for Gnome
[I] gnome-base/libgnomecanvas (2.30.3@10/27/2011): The Gnome 2 Canvas library
[U] gnome-base/libgnomeprint (2.18.6(2.2)@10/18/2009 -> 2.18.8(2.2)): Printer handling for Gnome
[I] gnome-extra/gnome-audio (2.22.2@09/06/2011): Gnome Desktop Sound Effects Package
[I] media-video/gnome-mplayer (1.0.5@01/16/2012): A GTK+ interface to MPlayer
[I] x11-themes/gnome-icon-theme (3.2.1.2@12/31/2011): GNOME default icon theme
Found 8 matches.
I think a couple of them can be un-merged, but just not all.

As a Linux user, more or less, you need to compromise with a few packages or libraries. Linux is a diverse world, for just one task, you may be able to find ten libraries which can do the same job. When you find a program you like, it's possible that it uses a library you don't like.

That's what Linux is and that's the way it has been, but some people don't like that and other don't want any changes to it.

Since a few packages of GNOME on my system, I only concern if the number of depending packages will grow. And if GNOME become an OS, the situation may get complicated.

Luckily, because of open source, if you don't like something, you are allowed to do something about it. Like MATE, a fork and a continuation of GNOME2. Only you need skills instead of a bitching mouth.

Now, looking back at the time when Windows still a program you needed to type win to run it. It was a Desktop Environment, although Wikipedia uses different terms, such Graphical Environment or Operating Environment, even Operating System. But it was never a OS since it didn't handle low-level operations, not I know of. Until Windows 95, things were packed together, Windows became OS since then.

It seems unavoidable that a Desktop Environment would evolve into a full OS, one way or another. It may not be the desires of developers but the users', anyhow, that's the direction, even you don't like it.

Even so, you should be glad that it's a DE, not a program which reads mail.

I am not really a fan of eye-candy stuff, but this one is really great. If I am still using GNOME, I wouldn't need any GNOME panels and default applets. With cairo-dock, it already contains all those things with beautiful images.

Here is a quick video clip, I didn't take much time to customize the dock, but it should be enough to show you how neat it is.


cairo-dock provides applet, program launcher, window list, a system tray, program menu, etc. It works well with Fusion and GNOME. Lots of fine settings that you can tune, background color, images, timing, sizing, font, etc.

If you take some time to adjust it, you should be able to satisify with it and to have a pretty clean desktop in GNOME.

Note: If you mess up settings, you can delete ~/.config/cairo-dock and start over again.
Note2: If you are using Fedora 10, you can install by running yum install cairo-dock{,-plug-ins,-themes} as root.

A day ago, I downloaded Opera 9.63/10a to give them a try within GNOME Desktop Environment. I then found out Compose Key and iBus didn't work. Opera now still only ships Qt3 for x86_64, there is Qt4 Opera. iBus has no problems with Qt4 applications. If you have Qt3 programs, you need to run by
XMODIFIERS=@im=ibus QT_IM_MODULE=xim qt3_program

About Compose/Dead Keys, you need to run by
XMODIFIERS= QT_IM_MODULE= qt_program

In fact, if the program is Qt3, then you only need QT_IM_MODULE=.

There is one thing you should be careful to claim if Compose/Dead Keys works or not. If you want to get é,
  • In KDE, you can only compose as follows: [compose]+[']+[e]
  • In GNOME, not only the sequence above, but also: [compose]+[e]+[']
Make sure you use correct sequence to test Qt applications.

However, I can not make both worked together, either I have iBus or have Compose key. I could only have one working in both Qt3 and Qt4 programs.

PS. If you are not sure what version of Qt is using, just check up HelpAbout [Program's Name], that will tell you what version of Qt it is using.



ChangeLog
  • 2009-01-22 Fixed QT->Qt