8 ms·

Regarding the UI, there are certainly some... curiosities. To give you a random anecdote from the trenches: https://bugs.documentfoundation.org/show_bug.cgi?id=

Regarding the UI, there are certainly some... curiosities. To give you a random anecdote from the trenches: https://bugs.documentfoundation.org/show_bug.cgi?id=107087#c16 https://bugs.documentfoundation.org/show_bug.cgi?id=107087#c... "It's challenging to fix as one needs to tunnel certain data through 20 layers of abstraction, but hey, that's improved UX for you!" If you want to get into triaging bugs, I welcome you with open arms. I am desperate to get us more helping hands as after nearly 10000 analysed reports I am anxious to diversify. Here is the index of our QA tech articles: https://wiki.documentfoundation.org/QA https://wiki.documentfoundation.org/QA Basic debugging info for triagers: https://wiki.documentfoundation.org/QA/BugReport/Debug_Information https://wiki.documentfoundation.org/QA/BugReport/Debug_Infor... Debugging for devs: https://wiki.documentfoundation.org/Development/How_to_debug https://wiki.documentfoundation.org/Development/How_to_debug Binary bisecting: https://wiki.documentfoundation.org/QA/Bibisect https://wiki.documentfoundation.org/QA/Bibisect If you were thinking of working on the UI, please get in touch with the design team, which includes some devs (but could really use 10 more!): https://wiki.documentfoundation.org/Design https://wiki.documentfoundation.org/Design You will find me in the QA IRC channel (and most others): https://wiki.documentfoundation.org/QA/IRC https://wiki.documentfoundation.org/QA/IRC I'm heading to sleep now, though, but I hope to see you around!

ZenoArrow 9y ago
Thank you very much for the overview! I'll check out the QA IRC this weekend, and look through the links you've shared. Hope to see you around too. :-)
jancsika 9y ago
> "It's challenging to fix as one needs to tunnel certain data through 20 layers of abstraction, but hey, that's improved UX for you!" It it's truly 20 layers of abstraction, I'd love to read a blog that spelunks into all those layers and elucidates what they do.
- chris_wot 9y ago
  Started in 1988, but since around 2012 we have started to streamline it. The layers work like this: 1. Old cross platform layer for both operating system specific functionality (OSL) and runtime specific functionality like string handling and bootstrapping (RTL). 2. UI code base is the Visual Components Library (VCL) - Window handling, event loop, controls (e.g. buttons, etc), etc.. This is divided into a platform specific part and a non-platform specific part (allows for easier porting). 3. “Starview Library” (svl) and toolkit Library with extra widgets, etc. 4. SFX2 (Starview Framework v2) dies things like dispatches messages, creates a “shell” for each program. After that I get a bit lost, it it’s mostly app specific stuff. There’s also a component model baked in called UNO (Universal Network Objects) which is a network transparent component hosting environment - it’s what allows the use of Python and Java, with obviously a C++ specific purpose environment. It’s kind of cool, but also many folks don’t want to use it any more than necessary. I think it helps to understand that it was a German company who created StarView, they really though in terms of layering :-)
  - gmueckl 9y ago
    I vaguely remember that StarDivision (the original company) offered separate licenses for the VCL as a cross-platform UI library in the 90s. If memory serves, it was available for DOS, Windows, OS/2 and Solaris back then.
    - chris_wot 9y ago
      And MacOS. It was reviewed by Dr Dobbs magazine, wish I had the original library source code! I’m a bit of a Libreoffice code historian, but there is no source code history before the year 2000...
      - exikyut 9y ago
        Not sure if you'll see this since I'm a bit late, but I have two questions: 1. I've been wondering this for a while but never knew who/where to ask, but where's the original StarOffice code dump? What actually got dumped? I'm fascinated by that whole transition timeline, both in terms of its own history and also as one of many code dump events. (One of these days I'll go learn about Mozilla.) 2. Are there any interesting tidbits floating around? Any old DOS-era or early-Windows-era code, for example? I wonder if (with great effort) I could build something for Win3.1. (Of course I realize I'm not describing LO at all here) 2000 is pretty old, as tech goes, surely something fun got captured. The only reason I can see for super-old code not floating around somewhere is that it was explicitly excluded.
voltagex_ 9y ago
Do you think someone (with a programming background) can help in say, 2 to 4 hours by just jumping in, or am I going to cause more harm than good?
- scrapcode 9y ago
  This articulates almost every experience I've had with trying to contribute my time to any open source project that has any size. I really think I've figured something out that'll help. I spend many hours getting X codebase to compile / work on my machine. I fix said issue and feel great about it! It never even gets looked at and/or it gets smashed to shreds with criticism by the same person that submitted the feature req / bug / whatnot.
  - Zancarius 9y ago
    I feel you, especially as someone with a bit of social anxiety any time I think I'm doing something helpful or useful (like writing this comment), because that concern is always in the back of my head. I don't have any particularly good advice that you likely haven't read or heard before, but sometimes it's useful to read/hear it from others who've been in the same boat. In my experience, and this goes doubly so for small FOSS projects, you have to remember that it's someone else's baby. Maybe they were the person who started it, maybe they've been there since the early days, or maybe they have an unusually strong attachment or sense of ownership over whatever it is you're changing. At any rate, the moment you submit a patch, there's always the risk that it may be met with harsh criticism (sometimes deserved; sometimes not), and at least part of that may be the nature of the human psyche. So, the best defense is to do things by the book, if there's an established process, or failing that, persistence. Sometimes, just the existence of a patch in the wild--even if it isn't accepted by the developer--can be enough to motivate them toward a fix. I've seen plenty of relatively minor fixes get rejected only to be fixed hours later by a maintainer because the patch got them thinking. Let's be honest, even if it bruises the ego a little: As a user, I don't care how it gets fixed. I'm not in it for the glory. I just want it to work. There's of course the usual advice [1]: Keep your pull requests/patches short and targeted. Don't try to do too much, because larger, more widely reaching patches are likely to be ignored or turned down. Document what you can, why you did what you did, and what you intended to fix; but don't be too verbose (guilty, as you can see here!). Asking follow-up questions is instrumental if it's rejected, because there's probably something that was missed or overlooked. Of course, this doesn't obviate issues with projects that have a distinct lack of communication skills or toxic personalities. Ironically, I've had some luck with non-committal/non-responsive maintainers by forking small projects, applying my changes and moving on, only to find some weeks later that they want to pull my changes. In those cases, I never expected a fix--I just needed it to work yesterday--and I needed somewhere to publicly source the fixed copy from. That upstream wants the resolution as well is merely an added bonus. But the key is (polite) persistence. It's also the hardest to do if you don't want to seem rude or pushy. I also think that rejection and criticism play on our fear of failure (whether or not we admit it), which may kill participation. Just don't give up: Think of the other users who don't have your skill set to fix the underlying problem and consider that you're advocating for them! [1] https://www.atlassian.com/blog/git/written-unwritten-guide-pull-requests https://www.atlassian.com/blog/git/written-unwritten-guide-p...

ZenoArrow 9y ago

Thank you very much for the overview! I'll check out the QA IRC this weekend, and look through the links you've shared. Hope to see you around too. :-)

jancsika 9y ago

> "It's challenging to fix as one needs to tunnel certain data through 20 layers of abstraction, but hey, that's improved UX for you!" It it's truly 20 layers of abstraction, I'd love to read a blog that spelunks into all those layers and elucidates what they do.

chris_wot 9y ago
Started in 1988, but since around 2012 we have started to streamline it. The layers work like this: 1. Old cross platform layer for both operating system specific functionality (OSL) and runtime specific functionality like string handling and bootstrapping (RTL). 2. UI code base is the Visual Components Library (VCL) - Window handling, event loop, controls (e.g. buttons, etc), etc.. This is divided into a platform specific part and a non-platform specific part (allows for easier porting). 3. “Starview Library” (svl) and toolkit Library with extra widgets, etc. 4. SFX2 (Starview Framework v2) dies things like dispatches messages, creates a “shell” for each program. After that I get a bit lost, it it’s mostly app specific stuff. There’s also a component model baked in called UNO (Universal Network Objects) which is a network transparent component hosting environment - it’s what allows the use of Python and Java, with obviously a C++ specific purpose environment. It’s kind of cool, but also many folks don’t want to use it any more than necessary. I think it helps to understand that it was a German company who created StarView, they really though in terms of layering :-)
- gmueckl 9y ago
  I vaguely remember that StarDivision (the original company) offered separate licenses for the VCL as a cross-platform UI library in the 90s. If memory serves, it was available for DOS, Windows, OS/2 and Solaris back then.
  - chris_wot 9y ago
    And MacOS. It was reviewed by Dr Dobbs magazine, wish I had the original library source code! I’m a bit of a Libreoffice code historian, but there is no source code history before the year 2000...
    - exikyut 9y ago
      Not sure if you'll see this since I'm a bit late, but I have two questions: 1. I've been wondering this for a while but never knew who/where to ask, but where's the original StarOffice code dump? What actually got dumped? I'm fascinated by that whole transition timeline, both in terms of its own history and also as one of many code dump events. (One of these days I'll go learn about Mozilla.) 2. Are there any interesting tidbits floating around? Any old DOS-era or early-Windows-era code, for example? I wonder if (with great effort) I could build something for Win3.1. (Of course I realize I'm not describing LO at all here) 2000 is pretty old, as tech goes, surely something fun got captured. The only reason I can see for super-old code not floating around somewhere is that it was explicitly excluded.

voltagex_ 9y ago

Do you think someone (with a programming background) can help in say, 2 to 4 hours by just jumping in, or am I going to cause more harm than good?

scrapcode 9y ago
This articulates almost every experience I've had with trying to contribute my time to any open source project that has any size. I really think I've figured something out that'll help. I spend many hours getting X codebase to compile / work on my machine. I fix said issue and feel great about it! It never even gets looked at and/or it gets smashed to shreds with criticism by the same person that submitted the feature req / bug / whatnot.
- Zancarius 9y ago
  I feel you, especially as someone with a bit of social anxiety any time I think I'm doing something helpful or useful (like writing this comment), because that concern is always in the back of my head. I don't have any particularly good advice that you likely haven't read or heard before, but sometimes it's useful to read/hear it from others who've been in the same boat. In my experience, and this goes doubly so for small FOSS projects, you have to remember that it's someone else's baby. Maybe they were the person who started it, maybe they've been there since the early days, or maybe they have an unusually strong attachment or sense of ownership over whatever it is you're changing. At any rate, the moment you submit a patch, there's always the risk that it may be met with harsh criticism (sometimes deserved; sometimes not), and at least part of that may be the nature of the human psyche. So, the best defense is to do things by the book, if there's an established process, or failing that, persistence. Sometimes, just the existence of a patch in the wild--even if it isn't accepted by the developer--can be enough to motivate them toward a fix. I've seen plenty of relatively minor fixes get rejected only to be fixed hours later by a maintainer because the patch got them thinking. Let's be honest, even if it bruises the ego a little: As a user, I don't care how it gets fixed. I'm not in it for the glory. I just want it to work. There's of course the usual advice [1]: Keep your pull requests/patches short and targeted. Don't try to do too much, because larger, more widely reaching patches are likely to be ignored or turned down. Document what you can, why you did what you did, and what you intended to fix; but don't be too verbose (guilty, as you can see here!). Asking follow-up questions is instrumental if it's rejected, because there's probably something that was missed or overlooked. Of course, this doesn't obviate issues with projects that have a distinct lack of communication skills or toxic personalities. Ironically, I've had some luck with non-committal/non-responsive maintainers by forking small projects, applying my changes and moving on, only to find some weeks later that they want to pull my changes. In those cases, I never expected a fix--I just needed it to work yesterday--and I needed somewhere to publicly source the fixed copy from. That upstream wants the resolution as well is merely an added bonus. But the key is (polite) persistence. It's also the hardest to do if you don't want to seem rude or pushy. I also think that rejection and criticism play on our fear of failure (whether or not we admit it), which may kill participation. Just don't give up: Think of the other users who don't have your skill set to fix the underlying problem and consider that you're advocating for them! [1] https://www.atlassian.com/blog/git/written-unwritten-guide-pull-requests https://www.atlassian.com/blog/git/written-unwritten-guide-p...