Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WxWidgets 3.2

wxwidgets.org

Post reply on HN
Print view View original

31–40 of 84 posts

Re: WxWidgets 3.2

#31

Post by heavyset_go »

wrigby wrote: post #28
konkordat wrote: post #27

Earlier quoted context omitted.

It's LGPL license. I wouldn't touch it with a stick when thinking about a real app.

I’m truly curious, is this because it rules out distributing a statically linked binary? I may be misremembering, but I thought LGPL is completely fine for commercial apps if you’re just looking against the LGPL’d code.

LGPL stipulates that you should be able to link against your own version of the LGPL library you're integrating, that's to say a user should be able to run an app with their own version of the LGPL library if they want to.

For some app distribution channels, like with iOS apps, that can be difficult to impossible to actually implement given the control Apple has over app packaging and distribution.

Otherwise, you should be able to distribute a commercial non-LGPL app that uses an LGPL library just fine as long as you meet that stipulation.

As others have pointed out, WxWidgets ships with a modified LGPL license that makes this point moot, anyway, and makes it easier for commercial apps to comply with the modified license compared to the bare LGPL as they are free to statically link WxWidgets and distribute apps in compliance with the modified license.

Re: WxWidgets 3.2

#32

Post by api »

heavyset_go wrote: post #30
t0mas88 wrote: post #3

I used this 15+ years ago with C++, it was so much easier to do cross platform things that way and it had good performance. Now I think I have not worked on a native desktop app on at least 10 years. And everything I see others make is more hybrid, javascript, electron kind of things. The performance of that even though we have much faster hardware feels worse than what WxWidgets / C++ did 15 years ago...

WxWidgets still works well today, I've used it on desktop products with great success.

I think it just needs API modernization. That’s it. Then it would totally rock. It could be a thin “free” (template only) wrapper.

Re: WxWidgets 3.2

#33

Post by justin66 »

diego_moita wrote: post #21

wxWidgets has a sublime idea: an api that is just a wrapper over native controls. For cross platform frameworks it is fast and light. The very opposite of bloatware. But it also has a terrible flaw: its heavy-templated C++ api, hard to port to other languages. I don't want to get stuck on C++. I want to use Go and Rust. And all the wxWidgets ports to those languages suck, big time. Show me a solid wxWidgets for Rust…

This isn't really a fault in WxWidgets. It's not like there are any good Go or Rust UI toolkits.

Re: WxWidgets 3.2

#34

Post by heavyset_go »

api wrote: post #32
heavyset_go wrote: post #30

Earlier quoted context omitted.

WxWidgets still works well today, I've used it on desktop products with great success.

I think it just needs API modernization. That’s it. Then it would totally rock. It could be a thin “free” (template only) wrapper.

Definitely agree with this.

Re: WxWidgets 3.2

#35

Post by api »

heavyset_go wrote: post #31
wrigby wrote: post #28

Earlier quoted context omitted.

I’m truly curious, is this because it rules out distributing a statically linked binary? I may be misremembering, but I thought LGPL is completely fine for commercial apps if you’re just looking against the LGPL’d code.

LGPL stipulates that you should be able to link against your own version of the LGPL library you're integrating, that's to say a user should be able to run an app with their own version of the LGPL library if they want to. For some app distribution channels, like with iOS apps, that can be difficult to impossible to actually implement given the control Apple has over app packaging and distribution. Otherwise, you sho…

Would it be good enough on platforms like iOS to dynamically link, include the DLLs in the bundle, and tell people they are on their own if they want to switch them out?

You theoretically can.

Re: WxWidgets 3.2

#36

Post by waynesonfire »

72deluxe wrote: post #12
wslh wrote: post #10

Earlier quoted context omitted.

The same for a MS-DOS Clipper [1] application written 30 years ago. Sorry, with all due respect to the wxWidgets contributors, aesthetically wxWidgets (like many other UI libs) is not for 2022. [1] https://en.wikipedia.org/wiki/Clipper_(programming_language)

But it just wraps the native controls...? You're effectively saying that native controls are not for 2022...

I'm guessing OP meant it doesn't look like material ui.

Re: WxWidgets 3.2

#37

Post by butz »

Which version of GTK does WxWidgets use? Overview mentions "2.6 or higher", but Wayland support hints at GTK3, or am I wrong?

Re: WxWidgets 3.2

#38

Post by idoubtit »

IYasha wrote: post #23
diego_moita wrote: post #21

wxWidgets has a sublime idea: an api that is just a wrapper over native controls. For cross platform frameworks it is fast and light. The very opposite of bloatware. But it also has a terrible flaw: its heavy-templated C++ api, hard to port to other languages. I don't want to get stuck on C++. I want to use Go and Rust. And all the wxWidgets ports to those languages suck, big time. Show me a solid wxWidgets for Rust…

Why so negative, yo? If you don't want to get stuck on C++, stick to C! )

> If you don't want to get stuck on C++, stick to C! )

You can't use C directly with the official WxWidget library. For instance, here is the first line of WxWidget's manual:

"Welcome to wxWidgets, a stable and powerful open source framework for developing native cross-platform GUI applications in C++!"

Re: WxWidgets 3.2

#39

Post by inetknght »

ale42 wrote: post #13
wslh wrote: post #10

Earlier quoted context omitted.

The same for a MS-DOS Clipper [1] application written 30 years ago. Sorry, with all due respect to the wxWidgets contributors, aesthetically wxWidgets (like many other UI libs) is not for 2022. [1] https://en.wikipedia.org/wiki/Clipper_(programming_language)

> aesthetically wxWidgets (like many other UI libs) is not for 2022 wxWidgets applications are supposed to look native on every platform... what's the issue? Personally, I find apps with weird GUIs that don't look at all like the rest of the system very irritating. I would prefer developers to spend more time implementing features, and less making bling-bling UI things.

> I would prefer developers to spend more time implementing features, and less making bling-bling UI things.

So many apps twenty years ago had features that apps today do not. It was really frustrating to see instant messaging services regress in features as people migrated from one to another to a third to ... today's dumpster fires.

Re: WxWidgets 3.2

#40

Post by cafard »

amelius wrote: post #25
tut-urut-utut wrote: post #19

WxWidgets is nice, used it in the past at one ocasion. It's just that I don't have any desire to touch anything C/C++. If it had a Java wrapper so I can use it with Clojure, it would be another topic.

The python binding is very popular.

I used it some years ago. The PythonCard library made it very easy to use.
Post reply on HN