From: Axel J. <Axe...@ba...> - 2009-11-15 17:53:08
|
Two things from me: 1) Regarding the canvas replacement: Maybe I missed something but why should QGraphicsView not be suitable for the project? Implementing an own canvas on top of opengl or whatever is clearly not the main goal of the project and should be forwarded to some library 2) Regarding other software: Today a friend of mine pointed me to this software: http://fritzing.org/ It is a circuit design programm that has besides PCB and schematic view also a breadboard view. It is based on Qt4 and looks nice. They also have a working canvas. Best regards Axel --- Axel Jäger Developer basysKom GmbH Robert-Bosch-Str. 7 | 64293 Darmstadt | Germany Tel: +49 6151 3969-961 | Fax: -736 axe...@ba... | www.basyskom.de |
From: Axel J. <Axe...@ba...> - 2009-11-16 12:42:08
|
> My issue is that I really can't get a handle on the KDE4 porting > process. On the other hand, I'm fairly comfortable with the OpenGL model > so I have a much clearer picture of how it would work... Remember, that > negative coordinants are valid in ktechlab so that, normally, you don't > have to care about where stuff is in the plane. (there is a bug there > but it is easy to ignore.) So the problem is that QGraphicsView is only available in Qt 4.1 and you want to move to another canvas before the KDE4-port? Just in case there is some missunderstanding here: QGraphcisView can handle negative coordinates. Axel --- Axel Jäger Developer basysKom GmbH Robert-Bosch-Str. 7 | 64293 Darmstadt | Germany Tel: +49 6151 3969-961 | Fax: -736 axe...@ba... | www.basyskom.de |
From: Alan G. <ag...@sp...> - 2009-11-16 14:25:52
|
Axel Jaeger wrote: > So the problem is that QGraphicsView is only available in Qt 4.1 and you > want to move to another canvas before the KDE4-port? Just in case there > is some missunderstanding here: QGraphcisView can handle negative > coordinates. See, I didn't even know either of those two facts. =\ If there wasn't such a sharp discontinuity in APIs, build systems, and even development tools (which are still in *alpha*!!!) life would be easier. =( -- DO NOT USE OBAMACARE. DO NOT BUY OBAMACARE. Powers are not rights. |
From: P Z. <zol...@gm...> - 2009-11-16 18:20:19
|
On Mon, 16 Nov 2009 15:19:59 +0100, Alan Grimes <ag...@sp...> wrote: > Axel Jaeger wrote: > >> So the problem is that QGraphicsView is only available in Qt 4.1 and you >> want to move to another canvas before the KDE4-port? Just in case there >> is some missunderstanding here: QGraphcisView can handle negative >> coordinates. > > See, I didn't even know either of those two facts. > > =\ > > If there wasn't such a sharp discontinuity in APIs, build systems, and > even development tools (which are still in *alpha*!!!) life would be > easier. =( > Here is some motivational video for Qt4: http://www.youtube.com/watch?v=MXS3xKV-UM0 ;) |
From: Alan G. <ag...@sp...> - 2009-11-16 19:35:20
|
P Zoltan wrote: > On Mon, 16 Nov 2009 15:19:59 +0100, Alan Grimes <ag...@sp...> > wrote: > Here is some motivational video for Qt4: > http://www.youtube.com/watch?v=MXS3xKV-UM0 OpenCroquet could do a lot of that a few years ago... project basically evaporated for some reason. (or has gone to ground...) Anyway, the issue I have with such systems is the mutability of the space... is there something like an X11 protocol for such a space? how effective is it at allowing arbitrary code to interact with the space? I can really see how it would make a lot of things on my system more user friendly, especially combined with code visualization tools!!!! =P -- being able to organize tasks and activities by space not just desktop... Actually, that would qualify as Fuckin A. -- DO NOT USE OBAMACARE. DO NOT BUY OBAMACARE. Powers are not rights. |
From: Axel J. <Axe...@ba...> - 2009-11-16 18:03:16
|
If you have questions on how to do anything with Qt4, be it QGraphicsView or mapping some other thought on Qt4, just ask me. I do Qt programming for a living since half of a decade. Unfortunately I cannot give any advises on KDE because I use a mac for daily programming. That also means I would be happy if ktechlab sometime would compile also as a plain Qt application. That would make contributing for me a lot easier. I respect that this is a KDE application and will try to support it also as a KDE application but of course I cannot just load it into Xcode or Creator here and fix bugs. Best regards, Axel Jäger --- Axel Jäger Developer basysKom GmbH Robert-Bosch-Str. 7 | 64293 Darmstadt | Germany Tel: +49 6151 3969-961 | Fax: -736 axe...@ba... | www.basyskom.de |
From: P Z. <zol...@gm...> - 2009-11-16 18:10:10
|
On Mon, 16 Nov 2009 19:03:00 +0100, Axel Jaeger <Axe...@ba...> wrote: > If you have questions on how to do anything with Qt4, be it > QGraphicsView or > mapping some other thought on Qt4, just ask me. I do Qt programming for > a living > since half of a decade. Unfortunately I cannot give any advises on KDE > because I > use a mac for daily programming. That also means I would be happy if > ktechlab > sometime would compile also as a plain Qt application. That would make > contributing for me a lot easier. If you like to experiment, KDE exists for mac, too: http://mac.kde.org/?id=home > > > I respect that this is a KDE application and will try to support it also > as a > KDE application but of course I cannot just load it into Xcode or > Creator here > and fix bugs. > > > Best regards, > > > Axel Jäger > > > > --- > Axel Jäger > Developer > > basysKom GmbH > Robert-Bosch-Str. 7 | 64293 Darmstadt | Germany > Tel: +49 6151 3969-961 | Fax: -736 > axe...@ba... | www.basyskom.de |
From: Alan G. <ag...@sp...> - 2009-11-16 01:21:11
|
Axel Jaeger wrote: > Two things from me: > 1) Regarding the canvas replacement: Maybe I missed something but why > should QGraphicsView not be suitable for the project? Implementing an > own canvas on top of opengl or whatever is clearly not the main goal of > the project and should be forwarded to some library Great, you do that. My issue is that I really can't get a handle on the KDE4 porting process. On the other hand, I'm fairly comfortable with the OpenGL model so I have a much clearer picture of how it would work... Remember, that negative coordinants are valid in ktechlab so that, normally, you don't have to care about where stuff is in the plane. (there is a bug there but it is easy to ignore.) > 2) Regarding other software: > Today a friend of mine pointed me to this software: > http://fritzing.org/ > It is a circuit design programm that has besides PCB and schematic view > also a breadboard view. It is based on Qt4 and looks nice. They also > have a working canvas. Hmm, it's not in Portage (Gentoo)... I'm certainly not going to stop you from talking to them on behalf of ktechlab. -- DO NOT USE OBAMACARE. DO NOT BUY OBAMACARE. Powers are not rights. |
From: Matthew A. <sol...@gm...> - 2009-11-16 10:41:43
|
> > 1) Regarding the canvas replacement: Maybe I missed something but why > > should QGraphicsView not be suitable for the project? Implementing an > > own canvas on top of opengl or whatever is clearly not the main goal of > > the project and should be forwarded to some library > > Great, you do that. Sorry, that seems a little confrontational to me. I hope that's not how it was intended. Anyway, it seems to me that we have two competing approaches here. So I guess what I'm wondering is how the two of you feel about handling this; should both techniques be developed, or would the two of you be happy to list what you feel are the pros and cons of your own chosen methods, so that it can be discussed? |
From: Alan G. <ag...@sp...> - 2009-11-16 15:39:52
|
Matthew Ayres wrote: > Sorry, that seems a little confrontational to me. I hope that's not > how it was intended. > Anyway, it seems to me that we have two competing approaches here. So > I guess what I'm wondering is how the two of you feel about handling > this; should both techniques be developed, or would the two of you be > happy to list what you feel are the pros and cons of your own chosen > methods, so that it can be discussed? I am more or less indifferent to which solution gets done as long as something gets done. I, myself, am incapable of working on his solution right now so therefore I am biased towards my own approach. There is nothing more to it than that. -- DO NOT USE OBAMACARE. DO NOT BUY OBAMACARE. Powers are not rights. |
From: Julian B. <ju...@sv...> - 2009-11-17 09:02:07
|
On Monday 16 November 2009 02:15:29 Alan Grimes wrote: > My issue is that I really can't get a handle on the KDE4 porting > process. On the other hand, I'm fairly comfortable with the OpenGL model > so I have a much clearer picture of how it would work... Remember, that > negative coordinants are valid in ktechlab so that, normally, you don't > have to care about where stuff is in the plane. (there is a bug there > but it is easy to ignore.) What you are looking for is the GraphicsView stuff of Qt4. It's an abstract "painting-framework" and if openGL is available, it will be possible to use it as the rendering-engine. If not, it will fall back to whatever is available. This is part of the cross-platform features, Qt provides. bye julian |
From: Julian B. <ju...@sv...> - 2009-11-16 15:39:34
|
On Sunday 15 November 2009 18:32:22 Axel Jaeger wrote: > Two things from me: > 1) Regarding the canvas replacement: Maybe I missed something but why > should QGraphicsView not be suitable for the project? Implementing an own > canvas on top of opengl or whatever is clearly not the main goal of the > project and should be forwarded to some library Right, QGraphicsView is the way to go. I did some research in this sector and tried to solve this issue using kde's plasma. As it seemed quite promising in the first place, I cancelled that approach and will investigate into a more direct approach using QGraphicsView directly. I already got some testing code, but since the component model is somewhat flawed in it's actual implementation, most of the components need to be rewritten and new graphics (preferebly in svg-format) need to be created. bye then julian |
From: Matthew A. <sol...@gm...> - 2009-11-16 16:46:36
|
> Right, QGraphicsView is the way to go. I did some research in this sector and > tried to solve this issue using kde's plasma. As it seemed quite promising in > the first place, I cancelled that approach and will investigate into a more > direct approach using QGraphicsView directly. I already got some testing code, > but since the component model is somewhat flawed in it's actual > implementation, most of the components need to be rewritten and new graphics > (preferebly in svg-format) need to be created. I like the suggestion of SVG graphics, especially as the SVG standard has official room for customisation which may be useful. I would be happy to build up a library of graphics, if that meets with approval. How about a discussion thread to agree on what the interface for a base component class should be? |
From: Julian B. <ju...@sv...> - 2009-11-16 17:24:25
|
On Monday 16 November 2009 17:46:22 Matthew Ayres wrote: > > Right, QGraphicsView is the way to go. I did some research in this sector > > and tried to solve this issue using kde's plasma. As it seemed quite > > promising in the first place, I cancelled that approach and will > > investigate into a more direct approach using QGraphicsView directly. I > > already got some testing code, but since the component model is somewhat > > flawed in it's actual > > implementation, most of the components need to be rewritten and new > > graphics (preferebly in svg-format) need to be created. > > I like the suggestion of SVG graphics, especially as the SVG standard > has official room for customisation which may be useful. I would be > happy to build up a library of graphics, if that meets with approval. I gave that some thoughts and have a picture in mind, how to do this. There is already some code, but that still needs some work (I mentioned that earlier, today). I started implementation based on Plasma, which didn't work well. However, I created some svg-files for testing purposes. You can find them in the git-repo, I am using: https://krtek.asta.uni- luebeck.de/repos/KTechLab/tree/src/plugins/passive/themes/default/components?h=kde4- playground Since plasma is themeable, I tried to represent this in the directory structure. This is most likely to be changed. > How about a discussion thread to agree on what the interface for a > base component class should be? Sounds good. I will start a wiki-page, documenting, what I found out during my research. I'm not sure, if I can finish it this evening, but I will do so tomorrow in the morning (my timezone is GMT+1). bye julian |
From: Alan G. <ag...@sp...> - 2009-11-16 19:17:38
|
Matthew Ayres wrote: > I like the suggestion of SVG graphics, especially as the SVG standard > has official room for customisation which may be useful. I would be > happy to build up a library of graphics, if that meets with approval. I read the wikipedia entry on that. Okay, so it's an XML format... I have not been able to find any authoring tools yet (much less figured out how to use them...) It is very reasonable to do this prior to the KDE4 port because the existing code does essentially the same thing in QT3 calls written in C++. Converting these to SVG sounds very reasonable. I just don't know how to do it myself. =P For one thing, this conversion would remove a ton of Qt3 calls, and lots of dodgy code. There are some places where the shape of the component needs to be responsive to the configuration of the part. It seems reasonable that dynamically generating/editing the SVG in those cases should work. One thing I would like to see is the standard ---/\/\/\/--resistor symbol in place of the existing box shape. Let me know what you need to move forward with this. > How about a discussion thread to agree on what the interface for a > base component class should be? I'm not sure what you mean. -- DO NOT USE OBAMACARE. DO NOT BUY OBAMACARE. Powers are not rights. |
From: Julian B. <ju...@sv...> - 2009-11-17 08:58:08
|
On Monday 16 November 2009 20:11:45 Alan Grimes wrote: > Matthew Ayres wrote: > > I like the suggestion of SVG graphics, especially as the SVG standard > > has official room for customisation which may be useful. I would be > > happy to build up a library of graphics, if that meets with approval. > > I read the wikipedia entry on that. Okay, so it's an XML format... I > have not been able to find any authoring tools yet (much less figured > out how to use them...) There is inkscape and karbon, as examples of vector-graphics editors. But since we use only small snippets of xml-code for one component, a text-editor will also do for most of the work. > It is very reasonable to do this prior to the KDE4 port because the +1, that's why I'm working on that > One thing I would like to see is the standard ---/\/\/\/--resistor > symbol in place of the existing box shape. ;) I had exactly that case in mind, when first thinking about it. I wanted the US-symbol for resistors and the DIN-symbols for all that logic stuff... > Let me know what you need to move forward with this. I am working on the Qt-part of that. bye julian |
From: Matthew A. <sol...@gm...> - 2009-11-17 09:04:36
|
>> I like the suggestion of SVG graphics, especially as the SVG standard >> has official room for customisation which may be useful. I would be >> happy to build up a library of graphics, if that meets with approval. > > I read the wikipedia entry on that. Okay, so it's an XML format... I > have not been able to find any authoring tools yet (much less figured > out how to use them...) For my standard SVGs I use Inkscape, which is fantastic. We can always expand the SVG DTD/Schema (which ever we decide to use) for our purposes and add in code (and strip unneeded code) in a text editor. It looks as though Julian is already working on the SVGs so I guess I'd risk duplicating work? > It is very reasonable to do this prior to the KDE4 port because the > existing code does essentially the same thing in QT3 calls written in > C++. Converting these to SVG sounds very reasonable. I just don't know > how to do it myself. =P Agreed, naturally. > There are some places where the shape of the component needs to be > responsive to the configuration of the part. It seems reasonable that > dynamically generating/editing the SVG in those cases should work. Yes, that would be particularly nice. I can think of a couple of examples (LEDs for instance) but if you would like to list the ones you're thinking of that might be helpful. > One thing I would like to see is the standard ---/\/\/\/--resistor > symbol in place of the existing box shape. My understanding is that the box symbol is the international standard. It's certainly what every textbook I've had has used ;) However, it might be worth having a little function in the GUI to switch between the two systems, especially if there are more differences. >> How about a discussion thread to agree on what the interface for a >> base component class should be? > > I'm not sure what you mean. Julian has indicated he's taking care of creating the discussion space. But what else I mean is that we should have a clear idea of what the software interface will be for the base class (non-visual) in the component hierarchy should be. |
From: Julian B. <ju...@sv...> - 2009-11-17 09:54:57
|
On Tuesday 17 November 2009 10:04:25 Matthew Ayres wrote: > It looks as though Julian is already working on the SVGs so I guess > I'd risk duplicating work? Nope. I just created some examples for testing purposes to start with the logic behind these SVGs and visualise them in a QGraphicsScene. > > One thing I would like to see is the standard ---/\/\/\/--resistor > > symbol in place of the existing box shape. > My understanding is that the box symbol is the international standard. > It's certainly what every textbook I've had has used ;) However, it > might be worth having a little function in the GUI to switch between > the two systems, especially if there are more differences. The box is the DIN-symbol. As I said before, I want to have something like themes, to satisfy everybody ;) bye julian |
From: Matthew A. <sol...@gm...> - 2009-11-17 10:07:41
|
>> It looks as though Julian is already working on the SVGs so I guess >> I'd risk duplicating work? > Nope. I just created some examples for testing purposes to start with the > logic behind these SVGs and visualise them in a QGraphicsScene. Okay, so shall I do both graphics and code customisation? We'll still need to discuss what tags will be needed. At the simplest level we'll need to mark some points as positive and negative, or reversible. But that would quickly become inadequate, no? >> My understanding is that the box symbol is the international standard. >> It's certainly what every textbook I've had has used ;) However, it >> might be worth having a little function in the GUI to switch between >> the two systems, especially if there are more differences. > The box is the DIN-symbol. As I said before, I want to have something like > themes, to satisfy everybody ;) Gotcha. I'd be happy to separate the graphics out into various libraries. |