SKUI — A GUI Framework for SketchUp
-
@thomthom said:
I'm wondering if the image perhaps fits better as an IMG element that sits in line with the text? Then the Button control could have some properties to control if the image to the left or right of the button text. ?
Hi Thomthom,
I don't understand exactly what you mean.
At first I just added a "click" event to the IMG element. But i figured that it would be better to approach them as real buttons.
This is the menu I'm rebuilding with SKUI:
I want the images to behalve as buttons that start tools and fold/unfold menu sections(groupboxes).Or would you take a different approach?
-
It all sounds good. I was just making a question on the details of implementation. At the moment you have the image set as a CSS background property.
But I was wondering if making the image an IMG element so that it could position itself relative to the button text. -
@thomthom said:
But I was wondering if making the image an IMG element so that it could position itself relative to the button text.
Ahhh, you mean like this?
<button><img src="icon.png" /></button>
That does sound better! -
Yea, something like that. It even allows for free positioning if you really need to - but will also add the extra option of aligning with the text.
That would be a nice improvement to SKUI.
-
You could even ship standard SU buttons, like (+), (-), etc.
-
@thomthom said:
That would be a nice improvement to SKUI.
I have added a pull request to the Github repository.
Let me know if you see any problems.
Btw I just noticed a different pull request which also adds images to buttons, but it seems to take a different approach... -
Hi TT,
As a response to your questions on Github.
What do you think of this approach?
If you could use the button as a container like groupbox the need for a background image would be eliminated... and the image class has all positioning methods you need(except maybe for z-index?).btn_hello = SKUI;;Button.new( 'Hello' ) { |control| name = control.window[;txt_name].value puts "Hello #{name}" UI.messagebox( "Hello #{name}" ) } btn_hello.position( 200, 0 ) btn_hello.tooltip = 'Click me!' window.add_control( btn_hello ) icon = SKUI;;Image.new('icon.png') icon.position( 0, 0 ) icon.size( 16, 16 ) btn_hello.add_control( icon )
-
Another question.
Do you recommend to leave the "core.css" file unaltered, and only add additional styling using themes?
I first completely uprooted core.css for my plugin in a way that all objects were relatively positioned and the fieldset would be automatically re-sized based on it's contents(normal html behavior).
But later-on I thought that doing all positioning from ruby/SKUI would better fit SKUI's design, even though it would take some more scripting to make everything line-up and re-size dynamically.
This would probably also prevent different behavior between browsers.Is this assumption correct?
-
Let me just step back a little (Sorry, I'm trying to catch up after coming home from the US).
The intent with the background image, is that to create a graphical button, or an icon glypth to go along with the button text? -
Traveling up and down to Boulder?
@thomthom said:
The intent with the background image, is that to create a graphical button, or an icon glypth to go along with the button text?
What I want to do is create graphical buttons, but an icon(like emoticons) in the text would be another option.
I also managed to set the background with javascript, works fine, but I think image buttons are so common that a built in option could be useful. -
Have you had a look at icomoon ?
Makes it easy updating sets which can be a pain if using png-sprites for ex.
( You can create your own sets in Illustrator. )Could be a viable solution.
-
Right - I was thinking in the lines of inline glyph. Sorry not not quite following what you where aiming for. I was mostly checking in from my mobile and I can quickly scanning the posts.
I see the use for both here.
What I'm thinking is that for the glyph, the existing Button can be extended. For the graphical button, I'm wondering if perhaps a new class makes sense... ?
Or maybe not.... (thinking out loud here...)Maybe Button.glyph=
and Button.image_normal=, Button.image_hover=, Button.image_disabled=, Button.image_focused= ? -
@jolran said:
Have you had a look at icomoon ?
Never heard of icomoon before, but it does sound very interesting!
Do you know if exporting a project also includes your own uploades SVG icons? -
@thomthom said:
What I'm thinking is that for the glyph, the existing Button can be extended. For the graphical button, I'm wondering if perhaps a new class makes sense... ?
Or maybe not.... (thinking out loud here...)A new (sub)class, or maybe set a "type" for the button?
@thomthom said:
Maybe Button.glyph=
and Button.image_normal=, Button.image_hover=, Button.image_disabled=, Button.image_focused= ?this would work nicely for "use-case 2", but not for "use-case 1". And I can't think of a way to position it halfway a line of text...
Difficult to find a universal solution...
What I'm trying to do is only(at the moment) use-case 3 and 4. -
@unknownuser said:
And I can't think of a way to position it halfway a line of text...
OK, now I'm getting uncertain if icomoon is a valid alternative for you...
(From gathering your Picture. And how far you have come already in your setups )With Icomoon (or any font-Icon setup ) you could however include Icons anywhere in text, using it as a font.
By the looks of it you want an inline button, though. And that would require nested elements I presume(?) So universal solution might be tricky for that..
Here's an example of Icons in text(in a text-area), if it is of any help.
You just build a string and include the unicode value ( \ue606 for ex ) where you want that Icon. It's quite easy. But I feel now it's not as powerful as you wished for..
Styling is also very limited this way...
-
@unknownuser said:
Do you know if exporting a project also includes your own uploades SVG icons?
( btw don't know if it's off topic since the discussion is regarding glyphs )
Yes that's the whole reason I use it. In spite of the pros and cons of Icon-fonts I found this to be best solution for me since having many Icons that need to be updated irregulary.
Updating PNG-sprites is a pain in the a$ in the longrun..Project is contained in a JSON file that you upload that will contain Icon-information with current unicodes and woff's, oet's etc. Then from there you save a new file.
These files have to be reloaded in your Project after an update off course.I can't remember if there where any updates that had to be made in the CSS afterwards. Not many anyway..
It's been a while since I delt with this, but I can give you an idea of the workflow, if you want to try it out. And in that case can find further information at the Icomoon site.
Anyway here goes:
Well first off you have to create the art in Illustrator (or incscape whatever)
And save as SVG.I further compress the SVG with:
https://github.com/svg/svgo-gui
Gives reductions between 20-60 %
Then upload the Icon to the Project and make adjustements in the Icomoon ap. (move, scale)
It takes some experimentation because Icons can get blurry if borders fall in an inbetween pixel value.
So in Illustrator i set up a grid with the actual target destination size (for ex 24px) and try to keep artwork snapped to those pixels, even if we are dealing with vector-art!When Everything is setup. I can use the Icon as classes or as a inline data-Icon.
The data-Icon setup is not te be found on the Icomonsite if I remember correctly.
But if youre interested in it you can PM me.The fontstyle can also be used inside textareas with normal text and icons.
The backside of this of course is that the icons are unicolored. There are some tricks to use multicolored font Icons, but I wouldent use them, because the contain to much information and can get blurry when resized because they use a hatching trick..
If you are just going to use a few Icons, then it hard to beat plain png-sprites and classes.
-
Where does this stand at this point in time? I am doing a major project for the local neurology lab disguised as a Sketchup plugin. That way it will be easy to run on Windows and Mac and the project needs a 3D presentation. The University is all Mac but I have been a Windows guy since and before it was invented. I am at the point where the toolbar I created is just not good enough and need something better. I have done plenty of JS and related but if I can keep it all in Ruby I will be a lot happier.
This looks like just what I need. Anything I should watch out for to make it Mac compatible? In particular what will happen with Safari? Any clue?
BTW, TT, you have been a lot of help for me in the past. I have been using Sketchup since it was invented. It is by far my favorite CAD program and your plugins are excellent.
-
@unknownuser said:
(https://github.com/thomthom/SKUI/blob/master/README.md)":2v9dncx5]This project is at it's early stages. Many changes will happen. Please do not make use of it as of yet. It's available here in order to be able to discuss the project.
I would think this may need some tweaking to work with the new
UI::HtmlDialog
class.I see Jan Brewer opened an issue on this line:
https://github.com/thomthom/SKUI/issues/105 -
@evan said:
This looks like just what I need. Anything I should watch out for to make it Mac compatible? In particular what will happen with Safari? Any clue?
It should already be cross-compatible.
Not sure what scale of a UI you are looking for. SKUI have a set of common controls. but if you need special ones you'd have to construct your own. Got any mocks of what you are looking to create?
-
@dan rathbun said:
I would think this may need some tweaking to work with the new
UI::HtmlDialog
class.Yea, part of SKUI is the general control wrappers. Another part is the JS<=>Bridge - that's where HtmlDialog have new features that would require different handling.
I had been thinking of a general WebDialog/HtmlDialog wrapper that could interact with both underlying classes.
For SKUI I don't see any obvious benefit of HtmlDialog at the moment. Big part of SKUI was taking care of cross platform issues, which is already handled.
Advertisement