Report Offensive Message
it's not always about legacy apps
I have to look into Joli further. The last time the issue was seeming to require an account bound to online services. maybe I can pluck the touchscreen driver support out of it or duplicate that on a more flexable system. I'm trying to setup a touchscreen and browser with minimum OS behind it. From the oposite angle, a ChromeOS with a few management things below the GUI layer and no requirnment to bind the device to Google.
"
The problem with legacy app compatibility and support on tablets and other mobile devices is that vendors will take shortcuts, if they address issues at all, regarding the usability of a desktop GUI designed app on a touch-screen device.
"
I don't think that everything needs to be a touchscreen centric interface; that seems to sell the hardware platform short. Consider the N900. I use the touchscreen GUI apps primarily. A few particular GUI and mouse apps I have on there for use also due to lack of a touchy equivalent. I also have terminal apps which have no GUI equivalent and provide the same tool across all my OS platforms. Quality apps designed for the device specific UI are fantastic but when they do not provide the desired functions, it's nice to have the choice of leaving the vendor provided sandbox.
"The NT and Linux kernels implemented *traditionally*, are always going to carry the legacy garbage with them. "
You loose me here a little. We're talking about UI and userland; what does the kernel have to do with it? If we must include kernels, how is the kernel running under Joli not traditional in comparison to the kernel running under a different distribution? The only difference I can think of is what driver modules are included. I don't think there is much difference between the Apple IOS and OSX kernel. I figured Win8 would use the same NT kernel across userland versions just as Win7 does.
"
Those kind of tablets have been trying to get market share for years and failing. No one wants to do that kind of work on a tablet. They want to do that kind of work on a clamshell device or a desktop.
"
Yes, it's been the year of the Windows tablet convertable for well over a decade now and a great part of the issue has been imposing a mouse/keyboard UI on a screen input device. I just think there is a much more balanced middle ground inbetween. It doesn't have to be one or the other; full OS or minimal appliance sandbox and non shall meet between the two. That's bullocks. There I want the best of both worlds; GUI touch interfaces where apropriate and the rest of my tools available across my platforms.
But what is wrong with a dock or bluetooth keyboard/mouse at home and work in addition to the touchscreen input when mobile? Artificially limiting the capabilities of the hardware through the OS does not provide the user more benefit.
In terms of App cross over, consider Zim; a rather nice "wiki" stile text editor. The interface is fine across different form factors. It doesn't suddenly become unusable because it's on a ten inch high res touchscreen. The only real difference is the data input method and since it's a touchscreen, you're going to need an appropriate text input solution regardless of the application. The benefits; I can easily sync the user data across all my systems and open it with Zim installed on each. OpenSSH and Rsync mean I can push or pull from all my my machines (well, Filezilla on the Windows boxes but whatareyagonnado). The more complete OS stack provides value.
On my N900 I really like WifiEye's display of networks in range but it doesn't provide the same amount of information that I get from Airodump within a single display. On a sandboxed appliance OS, I'd be stuck with only one. I believe Android has a WifiEye build or something with the same bubble display of power and channel bleed but to get the more complete details of airodump or kismet; I have to first install a more complete OS with a conveluted unlocking process and addition of the missing userland components and that's only if they are available. If my device ran Debian with a device applicable UI then I simply choose to add the extra value; whammo, same valuable tools used across my other systems plus the value provided by the devices UI centric apps.
It simply comes down to enabling the end user versus artificially limiting the capabilities of the hardware on the user's behalf. A ten inch tablet (larger are in development) with a full general purpose OS and applicable UI versus a ten inch tablet intentionally limited in what it can do. Why should we strive to consumer functionaly limited OS running on top of full blown general purpose computers?
"
The problem with legacy app compatibility and support on tablets and other mobile devices is that vendors will take shortcuts, if they address issues at all, regarding the usability of a desktop GUI designed app on a touch-screen device.
"
I don't think that everything needs to be a touchscreen centric interface; that seems to sell the hardware platform short. Consider the N900. I use the touchscreen GUI apps primarily. A few particular GUI and mouse apps I have on there for use also due to lack of a touchy equivalent. I also have terminal apps which have no GUI equivalent and provide the same tool across all my OS platforms. Quality apps designed for the device specific UI are fantastic but when they do not provide the desired functions, it's nice to have the choice of leaving the vendor provided sandbox.
"The NT and Linux kernels implemented *traditionally*, are always going to carry the legacy garbage with them. "
You loose me here a little. We're talking about UI and userland; what does the kernel have to do with it? If we must include kernels, how is the kernel running under Joli not traditional in comparison to the kernel running under a different distribution? The only difference I can think of is what driver modules are included. I don't think there is much difference between the Apple IOS and OSX kernel. I figured Win8 would use the same NT kernel across userland versions just as Win7 does.
"
Those kind of tablets have been trying to get market share for years and failing. No one wants to do that kind of work on a tablet. They want to do that kind of work on a clamshell device or a desktop.
"
Yes, it's been the year of the Windows tablet convertable for well over a decade now and a great part of the issue has been imposing a mouse/keyboard UI on a screen input device. I just think there is a much more balanced middle ground inbetween. It doesn't have to be one or the other; full OS or minimal appliance sandbox and non shall meet between the two. That's bullocks. There I want the best of both worlds; GUI touch interfaces where apropriate and the rest of my tools available across my platforms.
But what is wrong with a dock or bluetooth keyboard/mouse at home and work in addition to the touchscreen input when mobile? Artificially limiting the capabilities of the hardware through the OS does not provide the user more benefit.
In terms of App cross over, consider Zim; a rather nice "wiki" stile text editor. The interface is fine across different form factors. It doesn't suddenly become unusable because it's on a ten inch high res touchscreen. The only real difference is the data input method and since it's a touchscreen, you're going to need an appropriate text input solution regardless of the application. The benefits; I can easily sync the user data across all my systems and open it with Zim installed on each. OpenSSH and Rsync mean I can push or pull from all my my machines (well, Filezilla on the Windows boxes but whatareyagonnado). The more complete OS stack provides value.
On my N900 I really like WifiEye's display of networks in range but it doesn't provide the same amount of information that I get from Airodump within a single display. On a sandboxed appliance OS, I'd be stuck with only one. I believe Android has a WifiEye build or something with the same bubble display of power and channel bleed but to get the more complete details of airodump or kismet; I have to first install a more complete OS with a conveluted unlocking process and addition of the missing userland components and that's only if they are available. If my device ran Debian with a device applicable UI then I simply choose to add the extra value; whammo, same valuable tools used across my other systems plus the value provided by the devices UI centric apps.
It simply comes down to enabling the end user versus artificially limiting the capabilities of the hardware on the user's behalf. A ten inch tablet (larger are in development) with a full general purpose OS and applicable UI versus a ten inch tablet intentionally limited in what it can do. Why should we strive to consumer functionaly limited OS running on top of full blown general purpose computers?
Posted by Neon Samurai
8th Jun 2011
