< Blogs - MANIK.IN >    
  Sections
Activities
Blogs
Downloads
Service
 

 

________________
Open-Source..Choi..2
Open-Source..Choices
GPLisation of fonts
Distributing a Distro
Kartik Purnima
________________
Back to Blog Index
 

 

Web Log _

Perspective and Skinning for Konqueror

Manik Chand Patnaik
Fri Jun 02 14:42:50 2006

This article has dialogues as if two persons are arguing over some matter. One is asking and the other is explaining the process. However dialogues crop up at selected places only where the reader is expected to put questions. Questions are in blood red and common answers are plain text and emphasized ones are in green. The explainer also puts questions at several places and those are to invoke thinking in the enquirer (read viewer, that's you).

A short anecdote is also there to ease up the mood and an old definition of Usability specially made by me showing a very different angle (many may disagree to it).

There are a couple of web references. If you find a broken link kindly point it out so that it may be relocated/substituted.

Before delving in the User Interface and Skinning issue it is worth understanding how an interactive application is born at the first instance.

Understanding - “How an Interactive Application is born?”

  1. The Programmer's Task

    Designing and programming the functioning of the program. Making a scratch implementation of the UI sans the Look n Feel and aesthetics stuff. The task of the programmer is the most difficult and time consuming.

  2. The Interface Analyst's Task

    Testing the scratch UI for ease of use and intutiveness. Propose changes for the Look n Feel to the programmer.

  3. The Graphic Artist's Task

    The graphic artist makes icons, gradients and colouration suggestions to the scratch UI to make it look Cohesive, Expressive and Intutive.

Generally in any Open-Source Interactive Application Development scenario the developers control the project. The interface analyst or the graphic artist seldom feature in the initial contributor list and even if some get interested in these task, their task is the evolution of the program is limited to suggesting models and mockups for improvement of the program. Finally it is the programmer's time constraints, wish, philosophy and aesthetics that control the release product. If the user of the application is not a party to the contributor list probably he does not feature any-where near and if he shouts too much, many a times the user gets blunt replies like “go and implement yourself”.

Same Application with a changeable UI

Here is a proposal: As most complains about an interactive program relates to its UI, let's make its UI modifiable without any programmer intervention (without even recompiling the program).

Modifiable GUI implementations are not new. The famous media application on Windows, WinAmp (ver 3 and above) provided for a fully skinnable interface. Many media applications use the same trick. (Have you tried the many interfaces of Noatun on KDE?) Skinning provides the flexibility of changing the UI at Run-time as per the user's wish while the functionality is kept static by the program's engine. A skin can show/hide functionality and the user can select a skin as per his wish.

Skin making is often done by people who excel in graphic designing. There is very less coding involved, any code is generally scripted for UI animations like shrink, resize,show/hide, glow, change the skin and such small animation functions. All these UI animations happen without touching the core program engine. Then what about the best Interface for the program? No one decides it. The user gets full control over how the program looks on his desk. As good graphic interface designers generally aren't coders, this move removes the final barrier from graphic design and mockups to programmed implementation. And the best part is the functionality offered by the program engine is kept untouched and the default skin (provided by the programming team as standard) can be loaded at any time.

Konqueror as a Test Case

Before we discuss the case for Konq, the Basic Questions First:-

  1. What is Konqueror? - It is a file manager, a document viewer and a browser.

  2. What is the problem with the present Konqueror? - It does many jobs and so its interface is too crowded. Its single GUI simply fails to be simple and effective for all the tasks it is able to perform because Konqueror happens to be a Do-It-All program.

  3. Have you thought of any simple and practical solution? - Of course Yes! Using Perspectives and Skinning The Do-It-All Konqueror can be provided with a much cleaner and functional interface without much fuss and users can either type konqueror --filemanager, konqueror --browser or click on links on their desk or type shell scripts like filemanager or browser to invoke the appropriate interface. And they can load up their favourite theme on.

  4. Are we not doing it by opening the web-browsing profile and other profiles? We have theming capability through the theme manager too. So why this?- If you still don't get my idea, just read on ...

File Management

Konqueror as a File Manager provides the features like the standard file browsers in Windows and Mac OS as well as the other open source DE i.e. Gnome.

    A small sampler of tasks of Konqueror as a file manager.

  1. List folder content (Sort, Group (Not Implemented), Thumbnail, Show context info or meta (Not Implemented, Properties can show meta))

  2. Button Navigate (Back, Forward, Up)

  3. Address Bar Navigate (Auto list probables while typing, Navigate on clicking go button or on pressing Enter, Clickable paths are under consideration)

  4. File/Folder Operations (Cut, Paste, Copy, Move, Trash, Delete)

  5. Access files over networks (Works a lot better than any comparable file manager as KIO simplifies network access)

  6. Find files and Folders

Are the mock-ups in KDE brain-storm not showing the same tasks again and again in different layouts? Are the tasks any different from other File Managers in other desktops? If you find file managers doing the same tasks then what prevents them to look similar? (Now it is getting tricky and dirty man!)

Is there a way to do it? Can you simultaneously implement http://www.kde-look.org/content/show.php?content=39993 and http://konqueror4.linuxdevel.net/ ? Along with an implementation to make it look like Winxp or Vista or MacOS or Photon?

Wait Wait Wait! - I will be coming to it but first let's find out about the other tasks done by Konqueror.

File Viewer

This operation is probably is the simplest. Click on a file and it will show up. That simple. However Konqueror does some task to show up the file:

    Identify and load the appropriate plugin and load the file. Here Konqueror acts as a simple container. If there is an available plugin for the file type then it would display the file. The plugin will have control on parts of the Konqueror UI and probably put some buttons and menu items specific to the file type for specific operations Example: navigation in PDF viewer part.

If viewing a file is so simple then while viewing the file all other Konqueror UI elements not specifically related to the specific file type still show up? Why not they simply hide themselves? Don't you think file viewing a separate task than file management? - Oh yes! I do and I am going to show how to hide all non related UI stuff later during discussing perspectives.

Browser

Konqueror as a browser provide all the standard browser interface elements. The tasks it perform are:

  1. Fetches the HTML file and KHTML renders it along with all supported media/graphics and plugins.

  2. Navigates Forward and Backword, Reloads page, Stops and visits and stores bookmarks.

Is it any different from other browser's tasks? Do FireFox, IE, Safari, Camino or Epiphany do other things? What I am trying to lead to is that if my favourite browser does the same operations as other browsers then why it cannot look or feel like the other browsers? Who is that usability/accessibility expert forcing his interface down my throat? Why I cannot still select my interface from a wide choice?

If you like the interface of other applications why don't you use them straight instead of hanging here and complaining?

Now, before answering I am asking you, Isn't your question encroaching upon my choices, preferences, emotion and philosophy?

Now back to the answer: Why I use KDE is a thing quite personal to me. It is an emotional and philosophical bondage since ver 1.0 and it is difficult to change what I feel about KDE or its File Manager or its Browser or IM. KDE has empowered me with choices on every front, be it choice of application or choice of theming or choice of customisation or personalisation. What I need now is a choice to simplify/complexify the UI of applications on my desktop so that my friends from other Desktops can feel right at home while working on my desktop. Let them feel the power of the engine right under the familiarity of their already-being-used GUI hood. Understand the fact that the engine of a car is quite distinct and more important than the steering wheel and paddles. Just join them with nuts and bolts to get functional. Don't run to the arc welder to weld it down.

If your head is on fire then cool down. Let me tell you an anecdote: Once I was on a friend's Mac and I found its menu bar fixed at the top edge of the screen. The menu bar of the active application is shown there and with the change in the active application the menubar changed. Soon I was using that style menu on KDE. Most of my other friends just couldnot accept it. However I liked it that way only. In my view the choice of choosing your UI's look and feel is usability and accessibility. Sometime back when the Gnome HIG hype was very much all over discussion forums I had written a definition of Usability. Let me place it here: Usability is a much variable term. Usability for me is not Usability for you and what's usability for you is crippleness for me. So after all what is Usability? Usability in my dictionary is a political term among software producing communities to control, restrict and direct the thinking and behavioral pattern of the users of their software.

Hey! The anecdote is over now. Let's go back to the topic.

 

- - - - - This Article is under GNU FDL with title as FC text. Contact Author for any queries.

 
      Site Design and Content ©2005,2006 Manik Chand Patnaik. All rights reserved. Contact webmaster for any usage related queries.