Announcement

Collapse
No announcement yet.

LXDE Desktop Being Ported To Qt

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Delgarde
    replied
    Originally posted by mangecoeur View Post
    It occurs to me that if LXDE is moving to QT, and Canonical have built a QTMir backend, that means future LXDE should be able to run natively on Mir with minimal effort.
    No, because a WM/desktop is a different beast from a regular application. Applications can be ported to Mir by porting their tookits, but the DE has much more integration with X - if you're going to manage windows, you need to know what a window is on the platform you're running.

    That's why most of the fuss around KDE is over the Kwin component, not over KDE as a whole. Porting a simple KDE-based app to Mir or Wayland is no big deal once Qt and other underlying libraries have support, but porting a WM (or WM-like code such as a task-bar) requires lower-level code to actually know about all the windows that need managing. A toolkit generally doesn't help much with that.

    Leave a comment:


  • HeavensRevenge
    replied
    C++ is not that much bigger or slower than C, it may be a few KB bigger from templates, but the abstractions it buys vs a C implementation far outweigh the couple of milliseconds of C run time vs C++.

    http://benchmarksgame.alioth.debian.org/u64/cpp.php for an example of why C++ is not slower, it also shows code size can be smaller and be more memory efficient and even be faster from better use of abstractions and without doing needles memory management for correctness and bugs to help develop actual features vs fixing mindless C bugs.

    Also Just because KDE is big and kind of slow and bloated doesn't mean one bit that the UI framework used to build it is bad and bloated. That is 100% the fault of the KDE devs for not caring about perf and is in no way the fault of the Qt framework.

    Leave a comment:


  • RealNC
    replied
    Originally posted by dvanzo View Post
    Anybody knows why text menu (first level) is in that language??????
    Because "LibreOffice" is called "LibreOffice" in Asia too. I've never seem the actual name of a project translated. If that happened, people wouldn't have a clue what software is installed.

    Leave a comment:


  • mangecoeur
    replied
    Originally posted by dee. View Post
    It won't. Face it, no one wants anything to do with Mir.
    Except, you know, all the people at canonical, and all the people using their software - which easily represents the biggest chunk of the desktop linux market (in anticipation: no, distrowatch numbers do not represent market share). And being the most popular means attracting the most software and driver support (c.f. Steam support, and GPU driver updates tailored to go with it). If you make a DE and you're not paying close attention to this trend, you're not doing your job very well.

    Although strictly speaking, the aim is that the vast majority of users won't need to have anything to do with Mir, they'll just get a desktop that works. When was the last time you bought a computing product based on its display stack technology?

    All i was saying in any case was that if you build a desktop on QT5 it should run on mir whether you plan to or not, that's the point of QT be cross platform to begin with.

    Leave a comment:


  • dee.
    replied
    Originally posted by mangecoeur View Post
    It occurs to me that if LXDE is moving to QT, and Canonical have built a QTMir backend, that means future LXDE should be able to run natively on Mir with minimal effort.
    It won't. Face it, no one wants anything to do with Mir.

    Leave a comment:


  • mangecoeur
    replied
    It occurs to me that if LXDE is moving to QT, and Canonical have built a QTMir backend, that means future LXDE should be able to run natively on Mir with minimal effort.

    Leave a comment:


  • Delgarde
    replied
    Originally posted by Thaodan View Post
    Hmm, PCman said porting from GTK2-> Qt is easyer than porting to GTK3.
    That seems very unlikely. To my knowledge, any code that compiled without deprecation warnings on the newer Gtk+2 versions stands a pretty good chance of compiling with little or no modifications on 3.x.

    During the Gnome 2.x to 3.x transition, most of the core Gnome apps supported compiling against both, with a ./configure flag to select one or the other. Migration consisted pretty much of fixing code to not use deprecated functions, adding a few ifdefs to cope with the few cases where the API was incompatible, then eventually dropping the 2.x support once everything was stable on 3.x.

    Of course, the key detail there is "deprecated API". If your Gtk 2.x code makes heavy use of interfaces that have been discouraged for years on 2.x, then you *will* have compatibility issues due to those interfaces being removed in 3.x. But if your 2.x code is in pretty good condition, the porting effort should be negligible.
    Last edited by Delgarde; 04 July 2013, 06:58 PM.

    Leave a comment:


  • liam
    replied
    Originally posted by skriticos View Post
    You forgot Fox Toolkit and FLTK.
    • WxWidgets: ewww. I wanted to like it, but it has these little bugs all over the place that make it.. well, ewww
    • SDL: Now you are mixing cattles with aliens. SDL is a great tool for bringing full screen OpenGL content to a platform (see Steam), but it's not what you'd call a general purpose GUI framework (you know, with input boxes, buttons and all that stuff). It's a layer below.
    • Clutter: It's dusty and out of active development.


    I like Qt though. It's cross-platform, quite versitale and powerfull and most importantly it's quite clean and nice to work with + it has good documentation.

    Edit: Of course, I would enjoy to see people produce alternatives.
    Are you sure about Clutter?

    Lots of stuff still to do.

    Still plenty of non-trivial commits.
    Since cogl was made into a separate project in 2011 that may've greatly eased the development burden on the clutter devs.
    Fact of the matter is that clutter may not have a great deal left to do, but I'm only guessing.

    Leave a comment:


  • TheCycoONE
    replied
    Originally posted by chithanh View Post
    I think you are both wrong. Windows historically uses UCS-2 and not UTF-16. Also UTF-8 is not significantly longer than UTF-16 for most human readable text, because spaces and punctuation (1 byte in UTF-8, two in UTF-16) eat up any savings for characters which are 3 bytes in UTF-8 but only 2 in UTF-16.
    Windows NT based systems since Windows 2000 use UTF-16, older Windows, and SQL Server use UCS-2 (some UTF-16 awareness was added to SQL Server 2012). The point that has been largely missed is that compared to UTF-8, UTF-16 and UCS-32 are much faster to interpret. Compare what strlen would have to do in each. UCS-32 -> bytes / 4. UTF-16 -> bytes / 2 + number of (even/odd depending on endian) bytes that match 0x1101xxxx. For UTF-8 you have to do something like count high 1s in current bit before first 0, jump 1 plus the number of 1s and add that number to the counter until we've reached the end.

    Edit: Also assigning a safe buffer to fit a certain number of characters would use more space, even though the resulting string will probably use less.
    Last edited by TheCycoONE; 04 July 2013, 05:04 PM.

    Leave a comment:


  • GreatEmerald
    replied
    Originally posted by scionicspectre View Post
    Remember, it's not fair to yourself to compare toolkits based solely on desktop environments that use them. I'm sure you could create a memory-hungry DE with EFL, if you do it wrong.

    Qt has been used for a long time in the embedded space due to its performance and portability. Take Qt on QNX (Blackberry 10), and many of the new mobile iterations of Linux since Meego. This was originally Qt made to run specifically on underpowered devices in very limited environments, and it did pretty well given the constraints.

    With the proliferation of cheap ARM devices that are more powerful than desktops from 10 years ago, there are increasingly less reasons to be concerned about targetting the traditional low-end of sub-128 MB RAM PCs without minimal hardware acceleration for graphics. I think Qt has done plenty to prove itself, while GTK 3 still has a ways to go on mobile. Of course, if you have very specific needs that only GTK 3 addresses, go for it.
    This. KDE is by default pretty resource-demanding (but not nearly as much if you compile it without things you don't need). It has nothing to do with Qt, though. Also, Razor-qt is showing quite nicely that lightweight Qt desktops work just fine.

    Leave a comment:

Working...
X