Opsi's SoC 2006

(not so) Final news

• I committed the initial Desktop plugin which resembles the standard planar desktop experience. While actually it's a bit limited, it does the job for now including vertical scrolling capabilities and supports multiple tabs. It supports three file categories in the desktop ( namely: ".desktop" files, directories and regular files (detected through their MIME type)). After getting rid of the infamous 666 (i'll tell you about it later), another problem was resolved. Now external jars can be included in the classpath for a SceneManagerPlugin before it's loaded, so I can access another tools that already live in the lg3d-incubator, which allows, for example, to open a directory using some of the available 3D file managers. This let my desktop thing to open directories that reside within it inside a well suited app.
• I worked for a long period in menu generation, mainly because my lack of solid xml knowledge, but also for some complex algorithms that finally resulted much easier. One of this refer to the way to process rulesets in an xml tree. As usually happens with trees, most algorithms are better expressed as recursive systems, but they also require a deep understand of the problem as a whole and as a part, so I needed a quite long period to get to it while finally the solution was quite simple and of course elegant (I will dedicate an article on it soon). Another interesting point with the parsing of the xml applications file is the concept of Merging, which wasn't a hard task, but also took more than I expected just because I'm so lazy that I needed like 4 days to realize that I was passing the wrong Node to a given method (I must say in my defense that there are many Nodes in the menu tree ;).
• Well, even with that hard corners, I was able to parse the full file, merge it with the other necesary files and generate the needed events, but I found a total showstopper when the StartMenu code almost completly ignored the events I was sending to it. This is still a problem (see Issue 678) and after a lot of unproductive debugging I decided to freeze the menu stuff and move to another things...
• ...In my last TODO list, there was a dark element (reflected in Issue 666) which refered to classpath problems when trying to load a SceneManagerPlugin from a jar file located in the ext/app directory. I left this concrete issue down in the tasks stack because I focused in the menu stuff, but after my another lock-up, it looked like a good moment to look at this again, which was a nice idea, because as soon as I started looking at the SceneManagerPluginConfig (the class responsible from creating a SceneManagePlugin from an xml object) I saw clear that it was only needed to add a property to add new elements to the classpath, before the SceneManagerPlugin is loaded. I needed a way to modify the classpath during runtime, a simple search gave me the answer, a cool hack that hijacks the accessor protection to call a protected method in java.net.URLClassLoader from my own package, isn't it cool?. After some cleanup, my patch has been included in the lg3d-core, which makes for my very first direct code contribution to the core ;) (Given that now I have very clear how to integrate a SceneManagerPlugin or a normal Frame3D in the incubator i'm planning to write an article on this topic for the The looking glass developer's blog, stay tuned there).

posted by Opsi @ 9:43 AM 1 comments

SoC biweek report #1

Things I've done

DesktopEntry interface

This interface defines methods to obtain some parameters that are common to all the possible file types the system must handle (.desktop files, directories and MIME based files). This interface defines methods to get the name of the entry, a name for the icon of the file and an actionPerformed method. More info on the three possible types follow (all this classes implement the DesktopEntry interface):

.desktop file support (FileDesktopEntry)

I've created a class that can load a .desktop file, identifying the possible categories it can hold and storing all the keys stored in the file within the corresponding category.As some keys in the file can be interniotalized using "[locale]" suffixes, so the methods that retrieve values for keys in a desktop file can also receive a Locale parameter. This way, the getName method from DesktopEntry returns a localized name for the file and getIcon obtains it's info from within the .desktop file, as actionPerformed does.

directory support (DirectoryDesktopEntry)

For directories we don't have to care about localization, just return directory name on getName and "directory" for the icon name. I tried to invoke fm3d to open the folder from the actionPerformed method but it didn't work (I have it in my TODO list)

MIME support (MimeDesktopEntry)

This one has been challenging as there doesn't seem to be a reliable way to obtain mime types in Java. I searched all over the net and all I found or was incomplete and buggy (dieyng with some file types) or just didn't identify most file types. So, i've been forced to go down freedesktop MIME database specification and do my own implementation that for now works quite well (but still resides in my TODO list). The disadvantage is that it needs to access some files that are only present on linux, enoguh for now, but i'll have to work on this issue at least for Solaris sometime (another TODO). Also the name isn't localized for this files, just file name, and the icon name is set to the mime type.

Icon theme support

All that DesktopEntryInterface files return a name for the icon that doesn't contain any path (except forr the FileDesktopEntry that can eventually return an absolute path) in it, and no file extension. There is another specification that defines how to locate icons in the system. Based on this specs i've also created an IconTheme class and an IconFinder one, with the later using the former to find an icon for a requested name and size. The IconFinder provides methods to find the icon for a name or for a mime type.

DesktopIcon class

Once we can create a DesktopEntry for any file and obtain an URL for the icon of that file, we can create a Container3D derived class that just needs a Pseudo3DIcon to have 3d icon and a DesktopIconLabel to show the name (TODO: Make icon label readable in all contexts). I also add some event listeners to highlight the label on mouse hover and to execute the DesktopEntry#actionPerformed() method on double click.

DesktopPlugin class

The objective of this stage in my SoC2006 experience is to build a "pluggable" SceneManagerPlugin (SMP) to handle the user ~/Desktop folder (and other ones at user pleasure) and keep it at hand. With this objective I created DesktopPlugin, an SMP that handles classes implementing another interface called DesktopPluginInterface (DPI). This DPI defines methods to populate the desktop, fit it to screen and obtain the plugin root (Maybe I should make DPI extend SMP and add those methods to it, this way the desktop plugin can be selected directly from the lgcfg file... or add a new property like "lg3d.desktop.pluginclass"...or...).

MatrixReorderableLayout class

This LayoutManager3D is supposed to lay the components it receives in a number of rows and columns with a given spacing, and also allow them to be moved within a limited region (never out of rows or columns). Well, it does that things, but is incomplete and doesn't support more elements than nrows*ncols (really it neither constrain the movement to a limited space).(BIG_TODO: Substitute this layout manager by InfinityScrollableLayout:+info, down in the TODO section)

TabbedDesktopPlugin

This is the first desktop plugin i've created. The idea is simple, put the folders selected by the user in a classical tabbed panel. This panel is scaled down and moved to the corner of the screen to avoid disturbing user workflow, and when the user moves the moves over it, it grows to 90% of screen size (TODO: and should move opened apps back) so user can select any icon on it (TODO:after an actionPerformed on some icon, the panel should shrink to the corner again). In this plugin there are three main components (Container3D):

1. panelComp: This container holds the common backpanel for all the tabs. Tha backpanel is wrapped by a detachable BranchGroup so I can substitute it on fitScreen.
2. iconsContainer: For each tab to show one Container3D is added to iconsContainer after filling it with DesktopIcon(s). Each of them uses the MatrixReorderableLayout (to be substituted).
3. shortcutsContainer: Using the HorizontalReorderableLayout, this Container3D is filled with TabShortcut objects (one for each tab) which are linked to the corresponding tab in the iconsContainer through a Hashtable. That TabShortcut class has a method to highllight it, and has a listener on MouseClickedEvent so it can notify the TabbedDesktopPlugin that it has gained the focus so it can highlight the correct one and show only the icons of it (whose container is taken from the named hashtable).

TODO next 2weeks

• code cleanup
• invoke some file manager on directory actionPerformed
• after an actionPerformed on some icon, the panel should shrink to the corner again
• refine MIME detection
• refine icon search
• Make icon label readable in all contexts
• Substitute MatrixReorderableLayout by InfinityScrollableLayout (this new layout will receive rowspacing, colspacing, heightlimit and widthlimit and will hide elements outside the limits. When this happens (icons out of limits) it should add scrolling buttons to let the user see icons outside).
• code cleanup (wops, it seems I must do a lot of code cleanup)

TODO later

• boost performance on load
• resolve issue with classpath when moved on incubator (+info)
• work on Solaris MIME detection
• When TabbedDesktopPlugin is scaled up it should move pre-opened applications back in the Z axis to avoid intersections, just like normal Frame3D apps do.(possible?)

I'm probably forgeting something but I must stop digressing now ;)

posted by Opsi @ 7:04 AM 0 comments

One video to play

posted by Opsi @ 3:03 PM 0 comments

First screenshot ever

I've been working today to get something visual to post in this blog, and something has come up.
Looks nice, doesn't it?

The code is insane and text alignment is not correct, but you can see some localization going on in the Kdevelop icon.

As you can see folders are also recognized and i'm working to integrate a mime recognizer to put icons for the files that are neither ".desktop" nor directories.

The layout is static for now, so I must work a way to make it reorderable. One possibilty would be to use a quite usual desktop approach:

1. Let user freely move icons on desktop, limiting him to not take icons out-of-screen.
2. Allow user to set icons to stay where they are left or to snap to grid.

posted by Opsi @ 6:17 AM 0 comments

Basic directories in specs

There is another specification in freedesktop that indicates where are located the files, that are refered in other specifications, in the user disk. The following table shows the possible environment variables that are refered in other specs, the value to be used for each of them if they are not present, or empty, and a short description of their meaning:

Anyway they won't be necessary until we begin with the menu stuff.

posted by Opsi @ 9:43 AM 0 comments

.desktop files internationalization

posted by Opsi @ 10:03 AM 0 comments

Basic .desktop file format

posted by Opsi @ 8:53 AM 0 comments

Congratulations!

posted by Opsi @ 8:10 AM 0 comments