On Tuesday, 23 June 2015 at 18:58:00 UTC, ketmar wrote:
> nope, X is a window system. it's windows which is *not* window system, but window system with very simplistic toolkit bolted on top of it. that was not a bad idea considering the hardware windows aimed, but now it's a legacy crap, and almost anyone is hacking around it.

That's just OO wrappers.

>> Knowing minimal size won't help you if the amount of information simply doesn't fit.
>
> somehow it still works for me.
>
>> Dialogs can be scrolled, but master-detail views can't:
>> master and detail views already reserve scrolling for themselves, so it
>> can't be reused for the entire window, well, at least it won't work
>> naturally.
>
> i believe that we should stop here, as we are clearly talking about different things. i can't even imagine why widget may want to "reserve scrolling for itself" and what that means. and i can't see why any part of window can't be scrolled, especially when you have a clear widget hierarchy, and detail views living in their own containers.

I'm talking about native UI getting screwed up on high DPI. Native UI is supposed to fit whatever space it's given, otherwise it works, but not as good as it's supposed to. Imagine your desktop doesn't fit the screen and gets scrolled. On the other hand web was supposed to be scrolled from the beginning, hence it can better adapt to different settings.

On Wed, 24 Jun 2015 11:44:09 +0000, Kagamin wrote:

> I'm talking about native UI getting screwed up on high DPI. Native UI is supposed to fit whatever space it's given, otherwise it works, but not as good as it's supposed to. Imagine your desktop doesn't fit the screen and gets scrolled. On the other hand web was supposed to be scrolled from the beginning, hence it can better adapt to different settings.

yeah. that's why people constantly complains that the very same web pages looks like crap on their mobiles, or on their desktops. a perfect fit!

as i told -- you have absolutely no idea about layouting, and why html model suxalot.

On Monday, 22 June 2015 at 21:50:22 UTC, Nick Sabalausky wrote:
> Interesting. I'll have to look into that more. (Such as, will it run on Android phones or does it need separate hardware?)

Well, the commercially-released phones (two so far from BQ Readers, and one to be put on sale in the EU either today or tomorrow by Meizu) all come with Ubuntu pre-installed, but from what I understand it should be possible to port to run on any device which Android can run on:
https://developer.ubuntu.com/en/start/ubuntu-for-devices/porting-new-device/

Embedded OS architecture isn't really my comfort zone, but as far as I can see, they use an Android-derived hardware compatibility layer where any proprietary components (drivers etc.) are isolated from the rest of the OS.  The idea is that the Ubuntu OS, the applications, and the hardware support can all be updated independently of one another, i.e. a manufacturer can't lock you in to a particular OS version through the need for particular proprietary hardware drivers.

On Wed, 24 Jun 2015 06:43:00 +0000, Ola Fosheim Grøstad wrote:

> On Tuesday, 23 June 2015 at 19:03:14 UTC, ketmar wrote:
>> 1. cassowary is dynamic solver, it can continuously adjust it's solution as more and more constraints are added. actually, that is one of it's core features.
> 
> Ah ok, but I suppose that would also mean that things may jump around during loading.

yes. yet cassowary tries to maintain stability of solution while it's sane -- it was created for GUI layouting, so authors tried to make GUIs with changing elements more or less stable.


> You should implement in D and build a GUI over it. ;)

i ported it to D some time ago. and yes, GUI lib that i'm writing now will support Cassowary as one of available layout engines. that's why i did the porting in the first place! ;-)

On Wed, 24 Jun 2015 06:38:38 +0000, Ola Fosheim Grøstad wrote:

> On Tuesday, 23 June 2015 at 19:42:53 UTC, Nick Sabalausky wrote:
>> Progressive rendering made sense back when you could literally watch each image on the page gradually get pulled in over the wire (and when the layout more or less matched the HTML as it came in over-the-wire). But now it's mostly just a clunky user experience.
> 
> It still makes a lot of sense. The key is to organize the page so that the top part is reach a stable state while the rest of the page loads.

with the current trend to make a page consisting of huge fullscreen image and three columns of useless bla-bla text under it, it doesn't really matter if you will see the page sooner: there is no useful information anyway. ;-)

On Wednesday, 24 June 2015 at 15:30:58 UTC, ketmar wrote:
> yeah. that's why people constantly complains that the very same web pages looks like crap on their mobiles, or on their desktops. a perfect fit!

That's because they are designed to be pixel-precise, like native UI, so they have the same issues with user settings as native UI. But poor design choice is a responsibility of the respective designer. Well, this was already said many times in this thread.

On 06/24/2015 03:25 AM, Joakim wrote:
>
> I simply disagree that taking one feature, multi-window UIs, is
> "convergence" in any meaningful sense, so you can say they've just
> become "desktops."  I've tried to persuade you and Kagamin otherwise and
> appear to have failed. :)
>

Well, I guess it's good that you disagree with that, because I never said it ;)  I never claimed that adding one feature alone is convergence. I keep repeating over and over that that PLUS all the other things I'm now tired of mentioning all collectively constitute something that lies in-between traditional "mobile" and traditional desktop, but you seem quite insistent on ignoring that.

And I'm also not saying they'll become desktops, as that directly contradicts the whole "lies in-between traditional mobileand traditional desktop" thing.


> Supposedly they've made voice translation work completely offline a
> little while back, though I'm not sure if they still use the online mode
> by default.
>

That's good to hear.


>
> As you said, editing can be done through a voice interface too. It's
> just not common yet and people are still getting familiar with that new
> voice editing process.  I bet editing could actually be made much faster
> through voice, particularly for large documents.  I agree with you about
> text email being preferable to telephone calls for many kinds of
> communication, but that's not relevant here, as you're sending a
> voice-transcribed text email if you're using voice translation.
>

I don't doubt that'll happen, it may even become widely popular. But I do seriously doubt it'll ever be as good as a more direct (physical) interaction. And I don't see that so much as a technological problem as a basic human nature one.

On 06/24/2015 11:34 AM, Joseph Rushton Wakeling wrote:
>
> Embedded OS architecture isn't really my comfort zone, but as far as I
> can see, they use an Android-derived hardware compatibility layer where
> any proprietary components (drivers etc.) are isolated from the rest of
> the OS.

I've always found it absolutely stunningly bad that Android doesn't do that already. I mean, they sort of do, but not very well.

Ordinarily, I subscribe quite strongly to Hanlon's razor[1], but in this case I suspect it may be a deliberate business decision to keep their hardware and telecom partners happy.

[1] "Never attribute to malice that which is adequately explained by stupidity."

On 06/24/2015 11:37 AM, ketmar wrote:
>
> with the current trend to make a page consisting of huge fullscreen image
> and three columns of useless bla-bla text under it, it doesn't really
> matter if you will see the page sooner: there is no useful information
> anyway. ;-)
>

Hear, hear! :)

On 06/24/2015 11:34 AM, ketmar wrote:
>
> i ported [cassowary] to D some time ago.

Github?