Tabs, article and brainstorming

[Jonas]

I read (skimmed thru) this article on my phone, and though I don't agree with it, the author do raise some intressting points. Is there a better way then tabs? (I have a feeling I'm thinking inside the box here)

http://www.omgubuntu.co.uk/2012/04/why-tabs-must-die/

I use tabs alot, in Firefox I have about 40 open, if it's possible I use tabs in any application I can. I'd like to see Muon suite to have the different parts of it in tabs. Even though I love tabs, there must be a better way, though I fail to grasp it now. Now I saw this application/kicker on KDE-apps
KDE-looks - http://kde-apps.org/content/show.php...content=149936
youtube video - http://www.youtube.com/watch?v=Z54zgOod0P0

I think that the programmer is on to something that may make tabs (within) applications go away. Would like to hear some more about it, maybe you understand the post on OMGubuntu better, or have a different opinion or angle.
I disagre with the article author that KDE have more layers, (i.e is less user friendly) in handling application instances and tabs. From my point of view, the Qt and KDE framework is to make the user in charge and change to his/her likings, thus this remove layers of interaction.

B.R

Jonas

[SteveRiley]

Forgive me if I missed any meta-points in the referenced article. It's a lazy Sunday afternoon, sunshine (in Seattle!) streams unabated through my large south-east windows, and a beverage with greater-than-zero ethanol content occupies my left hand.

The article begins with a reminder of how terrible the world was before tabs came along. At least for browsers, anyway. OS-based switchers would fill up too quickly -- I think that's a reasonable summary of the introduction. Next, we read about how tabs suck because, well, they lack consistency across applications. Thus, tabs must be abolished, and the operating system should take charge.

Uh, that sure felt like I just went around in one big circle.

[woodsmoke]

Hi Jonas.

Here are four ideas.

a) My Calypso menu app, written in java, would "float" on the desktop and was a "self-organizing map". It was originally envisioned as a "menu" to replace the present menu. However, it could easily be adapted to have tabs in the intersections of the map instead of menu items. However it was roundly derided by the developers because my website was too "garish", notice they did not criticize the app but because they were so dismissive of the website, the didn't "have the time" to look at the app.

b) Using Rekonq, or Chrome, both of which I do not like, I inadvertently made a "favourite" of the favourites page of the favourites. I then detached the "tab" and there were the favourites as a "page" floating on the desktop.

c) I regularly just put links in the "quicklaunch" widget, the one with the rocket on it. I have different links in different ones and put move them to a face of the cube, sometimes I have more than four faces, the launchers are on the "last" face. When I am working with say...don't know....stuff at the college, I go to the face of the cube that has the launchers and move the appropriate launcher to the appropriate face.

d) When I was at anothe "social distro" I used the "prizm" function to make clickable links to ....ALL..........and there are a LOT of them... of the "social sites"... I then placed them in a folder and advocated that we could provide them as a "folder" on the distro. It was not KDE based. A user could then open the folder on the desktop and have the links available immediately. I also suggested that the user could copy the desired links to another folder and just keep that folder open.

In the latter three cases above, the links could be made to open as a tab or as a new window.

HOWEVER..... it "could be" that the article is really advocating a solution in search of a problem. After all is said and done, it might be that the "tabs" work for most people because tabs work for most people.

just some ideas.

woodsmoke

[bra|10n]

Firstly I make the distinction between tabs and a menu structure from an o/s perspective. Tabs are a tool while the menu or 'search option' should be nothing more than a simple convenience. A complete and well laid out o/s should cater for invoking 'xyz application' with a minimum of keystrokes or point and clicks. When the application name/type required is unknown to the user, the o/s should accept hints e.g 'edit flower.png', and either offer to open the file or open 'flower.png' in the appropriate xyz application. This I believe is the ultimate goal of KDE's H.U.D.

Application tabs combined with workspaces as they already exist in KDE are more than adequate for the needs of most users I believe.

However with the recent advent of Activities in KDE, the possibility to extend this functionality further exists beyond merely grouping and initialising applications and files of a common theme. Imagine activities by 'function' if you will, e.g edit, where a range of editors, dictionaries, translators and templates could be at you disposal with a single click. Even new applications or add-ons for further download could be made available. Web-links to similar content/design indicators etc, the list is almost endless.

Let's not want to make the menu (or the journey) our main focus. Let's get on and enjoy the result (life).

[SecretCode]

Bump a week later because I've been away but I find this interesting.

The only thing that can safely be said is some people are not happy with the current state of affairs - evidence being that new paradigms keep getting developed by *some* developers and taken up enthusiastically by *some* users.

The lowest common denominator is windows on a single workspace. ... Actually if you consider smartphones, where windows are a second-class thing, the lowest common denominator is just "multiple applications", but let's restrict our thinking to real computers.

On top of having multiple windows, stacked or tiled or whatever with a task bar and/or alt-tab switcher, we now also have, depending on the OS/DE/WM:
- multiple workspaces or virtual desktops
- multiple activities in KDE
- tab groups in KDE
- window grouping in the task bar / dock / app switcher - in most OSes - grouped by app (or manually in KDE)

and depending on the app we have 'document' tabs inside the app.

But there are more, which the article doesn't mention:
- the tab groups that Firefox has introduced. I use them, but not very effectively and could probably do without.
- the various user applets in Windows, or application-specific coding, that allows people to "minimise applications to the system tray" - cleaning up the task bar and app switcher but still having an on-screen way to access the app
- and surely others

This tells me that there are lots of different ways that users want to, or subconsciously but naturally try to, interact with their applications and windows and documents. It also tells me that no one team of developers has a monopoly on understanding the needs! - I don't trust any development paradigm that wants to take away methods of switching between windows etc.

[woodsmoke]

I made a reply but then decided it was not a "reply" but actually a different idea so I made a new theread HERE.

woodsmoke

[SteveRiley]

This tells me that there are lots of different ways that users want to, or subconsciously but naturally try to, interact with their applications and windows and documents. It also tells me that no one team of developers has a monopoly on understanding the needs! - I don't trust any development paradigm that wants to take away methods of switching between windows etc.

I think you're on to something here. User interfaces are under constant evolution. Some people like change, others don't. GNOME 3 and Unity are forcing change on their users. KDE's approach is fundamentally the opposite: new paradigms emerge, and they co-exist alongside existing ones. Take, for instance, activities. While their presence is now undeniably visible, they can still be ignored. No one has to use activities. You can still work on a single desktop. Or on multiple desktops. Or you can explore activities. And even consider how they work together with multiple desktops.

This, among many other aspects, is what draws me to KDE over and over again. I try other DEs every once in a while but keep returning to this one!

[GreyGeek]

All this stems from the desktop metaphor.

When you use a computer you need to start someplace. The first thing you need is a clear space in which to begin work. This space is, in some metaphors, called a "canvas", borrowed from the painting metaphor. We do the things we want to do with computers by starting with a canvas. Some of us use a blank canvas to begin with. Others have modified it to include color, or perhaps a beautiful picture, called "wallpaper", borrowing from the home decorating metaphor. Some of us hang a clock, or a calendar or some other device on our canvas. Somewhere along the boarder of the canvas is a button which, when clicked, leads to a menu structure of some sort which contains links to activate applications stored somewhere on the computer HD. Some users "multi-task", or actually task-switch. Having more than one task (app) running on a single canvas sometimes results in a messy canvas, especially if an app was built using a Multi-Document user interface. The image on the task bar for each document makes switching documents easier, sometimes. So does Alt+F4, or its ribbon, if any. But, sooner or later, a user wants to have more than one canvas (now called "Activity") on which apps related to a specific task can reside. Apps written with a Single Document interface resolve this activity problem by creating another tab for each unrelated activity. Browsers are good at this. I have a tab opened on my KubuntuForums subscribed list, and when I read a thread in a topic I open it in another tab. On a third tab Google search might be found. On a fourth tab Wikipedia. If I have KWrite or Kate open they would appear as task icons in the task bar. To bring them to focus I click on their task bar icon. I open a pipeline for each tab that I plan to have, but usually settle on 8 pipes by default. Chromium can open 8 or more, along with a sand-box.

The KDE desktop has "pages". I keep a setting of two. I only use one. A page is a completely clean, new canvas except for any decorations you added. When you open an app in the second desktop, say Dolphin, it places its icon on the task bar at the bottom. That task bar icon does not appear on the task bar of the first page. The right side of the task bar, i.e., the application launcher (if you installed it) and the system tray, are the same on both pages. If you hoover your mouse over the page icon in the task bar it will show an image of and name the apps open on the canvas it represents. Instead of pages one could use the cube, a 3D tool which presents the canvases as sides of a 3D cube. Being a minimalist I decided against using the flashy cube. I use just one canvas and either ALT+F4 or the task icons to switch between tasks.

Many applications also use the Tab metaphor exactly the way the browsers use it. When writing a Qt based application one can add tabs to a window by using the QtTabWidget class. The QTabWidget is merely a BRICK. Nothing more. Developers do not begin writing each app from scratch any more than a home builder starts out by cutting down some pine trees. They visit the lumber yard (Qt API) and pick out the materials they want to build the structure they want. They combine the materials (2X4, block, brick, 4X8s, etc..) to create what they designed in their specs.

QtTabWidget is a class. Because it is a class it can and has inherited members of pre-existing classes, QtGui and farther up the chain, QtCore. One can use QtTabWidget to create their own customized class, say "MyTabs", by including QtTabWidget in the definition of their own class. Thus, all the public (and some private) functions and properties of QtTabWidget become part of MyTabs. As a bonus, if some bug was found upstream in QtGui or QtCore, the fix becomes part of MyTab when the patched QtGui or QtCore classes are downloaded and installed as part of a normal update. The next time the app that MyTab is used in is recompiled the bug fix is automatically passed along. If new features were added to QtGui or QtCore they are passed along as well. Win-win.

In Qt4 a collection of classes is called a "Module". QtGui is a module holding all of the user interface classes. ALL user interface classes inherit the QWidget class. There are two piece of Q4t documentation that everyone should read it is the details to QWidget and QObject:
http://doc.qt.nokia.com/main-snapsho...t.html#details
http://doc.qt.nokia.com/main-snapsho...t.html#details

QObject is especially important. It is the BASE CLASS of all Qt objects. It adds a lot of features to user created classes, : automatic garbage collection, signals and slots (events & responses), etc. It has several macros. To use the signals & slots capability of QObjects the Q_OBJECT macro must be included in the class description. Beginning with Qt 4.2, dynamic properties (class variables) can be added to and removed from QObject instances at run-time. Dynamic properties do not need to be declared at compile-time, yet they provide the same advantages as static properties and are manipulated using the same API - using property() to read them and setProperty() to write them. From Qt 4.3, dynamic properties are supported by Qt Designer, and both standard Qt widgets and user-created forms can be given dynamic properties.

All this stuff in nothing more than bricks, wiring, glass, sheet rock, shingles and concrete mix. Building tools. The hand tools are the editor and compiler. Kate or QtCreator, and gcc. Some people write concert music for a violin, others call it a fiddle and write bluegrass. it's all music, good or bad. If you are of average intelligence then half of the people of the world are smarter than you and half are not. If you have the time and interest you can write concerts or bluegrass on your keyboard. Regardless of what you write, if the others are happy with they write let them be. What matters is if you are happy with what you wrote. Tearing down the work of others never makes your work better.

[SecretCode]

Great points, GG ... or are they bricks ... now I'm confused

[GreyGeek]

... uh... just a minute ... I forgot!

[Jonas]

I like this brainstorming, glad to be on KFN, somehow I think that the capabilities of Qt and KDE can evolve into something better. I feel that I there's some things that could be improved yet hard to grasp atm, since I think "within the box". More suggestions please

b.r

Jonas