Il vaut mieux de commencer en petits pas. Peu importe à quel point on décolle, on ne sera pas finir à la première fissure à la lune.

Tu n'a pas besoin de faire des grandes choses comme FredoScale. Déjà après une journée on peut faire des petites choses utiles avec Ruby.

1. D'abord, tu peux goûter Ruby sur le web: http://tryruby.org
   En fait, Ruby est une langue de programmation qui essaye de sembler le plus à la langue humaine.

2. Si ça te plaît, tu veux certainement aussi faire des choses en 3d! Les dieux de SketchUp ont préparé un tuto, ça commence avec zéro et ça t'apprend tout ce qu'il faut savoir pour SketchUp: Ruby 101

3. Après, tu peux continuer ou par essais et erreurs, ou avec un livre, et toujours consultant les références de la SketchUp API et de Ruby.

I believe the answer "(yes|no) we (can|cannot) achieve this with plugins in the current SketchUp" depends on how we understand each other's imagination how SketchUp should work.

Plugin developers have no influence on the "core", and the scope, flexibility and capabilities of the core decide what wishes plugins can solve.

Can tomorrows's core be the same today's just with infinite performance improvements?

Anything in the range of 10^-15 is like an atom core on your finger (and the atom core is 1/10000 of the whole atom). In SketchUp models, this is usually not something we want to consider.

If you calculate using "virtual geometry" (from the Geom modue like Point3d), the SketchUp tolerance applies as well, like for visible geometric entities. The idea of SketchUp's tolerance is to compensate for rounding errors, because when you calculate a length one way and compare it to a theoretically same length that is calculated in another way, you want them to be equal. It is so that we developers don't need to think about it.

Try:
Geom::Vector3d.new(1,1,0) == Geom::Vector3d.new(0.999999,1.000001,0)
If a segments fits 3.999999 steps into a length, we can see it as the same as if it fits 4 times.

This is because SketchUp introduced a "Length" class, and only this has the tolerance. Integers and Floats don't have SketchUp's tolerance, but Ruby's precision with (machine epsilon).

All numbers that you obtain from geometry are already of the length class. All numbers that you obtain from floats automatically turn into Length when add/multiply/calculate them with lengths. Check that your numbers are of the Length class:
` a = vector.length
a.class

Length
b = vector.x
b.class
Length`

What are you trying to do? If a "split" gives a value near an integer (or a difference near zero), then it is usually not relevant for SketchUp geometry. You can't create edges of such short lengths. What are you trying to split?

I cannot reproduce this in SketchUp 7.1 (Ruby 1.8.0) to SketchUp 2013 (1.8.6) and Ruby 2.0.0. But I remember I once had an example that gave 0.999… or 1.0 depending on the order of operants. I can't get it to work again on my 64bit processor (maybe it gives a different result on a 32bit).

Did you select these numbers to invoke this problem for testing, or does this really occur in practice in your plugin? If so, wouldn't it be better to use Math.round instead of truncating with to_i?

As for workarounds, precision is usually not a problem I need to care about, especially since SketchUp has its own tolerance where unprecise floats still fit in. If you really deal with big numbers or need highest precision, you could use BigNum or Rational.
Otherwise it often helps to rearrange your calculation to avoid adding big and small numbers (or using offsets).

That's possible.
Can you give a reduced example that includes the values of delta_t4, lstep, reste, and with readable variables like a, b, c.

Also to_i truncates (rounds towards 0), and does not round to the nearer full number.
puts turns the input into a string, so it is a good idea to test with to_s (or inspect) to exclude the case that the problem is in the numeric to string conversion.

@mike lucey said:

Surely it would make sense that 'SketchUp Ultimate' should come from the SketchUp Team or an 'extended' SketchUp Team

With the secrecy that they have (and have the right to have) about future plans, do you think a forum could do funding and held up a feature request analysis with them "in the open" without also having open feedback of the development progress of these specific features? I think it's worth to follow this approach of community-SketchUp interaction.

Will SketchUp always continue building incremental improvements on the same basis?

Oli's vision of a modeling application that is

• convergent as in bridging the borders between devices, operating systems and input methods on one side
• and convergent as uniting advanced professional usage and light, occasional, creative usage into one single interface that can transform and satisfy for any situationthis is quite innovative, but would need to rethink 3d from scratch, and design the platform from the ground up to be scalable, extendible and usable on all different screens and devices. Imagine your favorite program would be ready to use either on a desktop with 3d glasses, with fingers on a tablet, or with a 3d pen or hands and a AR-glasses (video). Like wood-working and pottery take place in real space and use various tools depending on the situation, the same should be true for 3d modeling.
  This could be the next step in 3d!

The ghost of a community-driven SketchUp alternative/successor has already several times come up (search for "OpenUp"). Users come to the conclusion they cannot bend SketchUp to fit their requirements for feature richness, performance, platform-availability. Some of them have converted to the "other" software, but for many it's hard to leave SketchUp because SketchUp has just enough goodness to make the decision so difficult.

@olishea said:

If you want to model a simple house from house plans, then go for it. If you want a highly complex organic model with perfect texturing, then go for it! Why should we need to use several different programs to achieve this?

Oli, I cannot resist imagining a world with the app that you describe, but did you do a feasibility analysis?

For anyone (community, company or Trimble) to develop a SketchUp-like but better application with the same maturity of preformance, inferencing, ecosystem, etc., it would take years to catch up to where SketchUp is now.
Users would still use and thus support SketchUp until an alternative is exactly on par with the original, even if its goal would explicitely be not to be a clone, people will try to compare it.
Is there enough momentum to develop (and finance! How much did Trimble invest to own SU?) something that will be for several years behind any commercial or free-as-in-beer alternative, with a small team of developers (that may not all have the required low-level technical skills), with the risk it could loose momentum and never reach its goal, and with the outlook it will never work our extensions (because implementing an analog API is forbidden) and with a negligible awareness level (new users would always discover "SketchUp" first in search results).
That is yet without numbers and estimates…

However this topic shows there is something wrong: If SketchUp is not flexible enough to be "bent" to users' needs, can it claim to be a "platform"?
What do we expect from a platform so that we'd favor extending it rather than building a new platform from scratch? (→ wishlist thread)

Such webdialog issues have been discussed in many places elsewhere (like here), I think it's not too far fetched to say the skp: protocol is unreliable and for many use cases "dead". It does not only need url-encoding ( %) + string escaping ( \), but it also looses certain combinations of characters. When it returns the string url-decoded to ruby it causes ruby to have issues with some decoded characters.

I suggest to use skp: only for a small set of known identifiers of limited character range (names of your callbacks).
If you need to transfer user data (that could potentially contain any character like quotes or Chinese), let the Ruby API fetch the string from a hidden input field using get_element_value.

Me and thomthom do this for all communication between Ruby and Webdialogs using a message pipe (see thomthom at github, or mine). Please don't waste too much valuable time with webdialog issues, but try to re-use what we have already worked out.

The purpose of an API interface is to hide its implementation details. It would be good if SketchUp incorporated a repaired or new communication model as default, so that developers can make plugins "on top" of the API instead of working around issues below the API.

Let's better not use pixel sizes to dimension anything that will contain text.
Every box that contains text is better dimensioned with em.

<select> elements can appear differently in various browsers (especially if you would want to use CSS on the option elements). There is probably nothing wrong in your implementation, but in the specific browser used.

Usually the operating system's native controls look native and have besides mouse support also good accessibility for keyboard navigation, screen readers, scroll wheel. They have the behavior that the user expects to work.
I don't think it is worth the effort to "imitate" a <select> using <div>s for cosmetic reasons that only appear in a minority of browsers. Of course it's another case if you need to do something that is not possible with the native control (including images and small paragraphs in options, etc.).

@thomthom said:

The advantage of GitHub is that "everyone" is there already[…]

I agree with thomthom. If I was a fish, why should I make the jump from the ocean into a pond?

I don't see so enough activity on github projects that it's worth the effort to migrate them once here once there. Wouldn't it do it if we just improve the linkings between SCF and code hosting sites (and everyone can enjoy there prefered code hoster, including bit bucket). Maybe a "source code" tab in the plugins store (next to "documentation" and "release notes").

And and improved and visible button for issue reporting. Users still abuse ratings to "report" something. This is extremely demotivating and unthankful to the developer, and the developer still has no clue what is wrong. I delete (and have deleted) plugins if users don't appreciate the work.

On the other side, if it was possible for users to use an issue tracker without registering an extra account somewhere then there would be a remarkable advantage.
And automatic building, packaging and publishing etc.

The original suggestion was to make it easy for all SketchUcation members to translate each of our plugins to their own languages (via an online-hosted translation management system like it is used for OpenSource software, maybe you've seen it at Mozilla or Launchpad). It is much more efficient and has a low entry barrier, and no single user is forced to do 100% of the work. Translating together is fast and fun.

@tt_su said:

But are you guys talking about a system to upload a translation specific to each extension or to generate a pool of generic translations.

Each plugin would be translated individually, with based on .strings files as you already have, but hosted online (like you can host code in git/mercurial/bazar).
While such systems often feature a translation pool and bindings to machine translators, that is only as help and does not replace human-made quality translations.

Now in this context there are also other ideas (that we could of course discuss also, maybe even in their own topics):
• unified translation framework for Ruby plugins (like LangHandler?). If LangHandler actually was good enough to replace my own Translate library, and if it was backported and available on all SketchUp installations, that would be best.
• developing a translation tool integrated in SketchUp
• SketchUp preference for language priority (How many secondary/third languages would people set up? Could this be achieved inside SketchUp or its API?)

I would be also interested to see some strategies shared and learn from how other developers do unit tests.

When experimenting with unit tests I learned that it is important to distinguish between "unit tests" (tests an individual method's output for the range of possible input) and "integration tests" (tests the end result of what a plugin and all its components/methods does after being launched).
Also test only your interfaces (think of "your API") and not technical implementations that you might change somewhen ( @@variables).

Simple ruby methods are often so obvious that writing unit tests for them distracts you from the real important things that are more likely to break. And the integration is hard to test and error-prone, because

• webdialogs are often asynchronous and need user input (ie. your test runs to the end without receiving a result from the dialog)
• webdialogs have JavaScript code. While there are JS unit test frameworks, your code might depend on the Ruby side which makes it complicated.
• trying to automate the webdialog by injecting JavaScript leads to hacks, and you have to fix the test more often than the real code you are trying to test.
• you cannot make private JS functions public

You can make private Ruby methods public with (for example):

def setup
  # Make all private methods public.
  (MyPlugin.private_instance_methods - Object.private_instance_methods).each{ |method|
    MyPlugin.instance_eval{ public method.to_sym }
  }
end

Attached is a (incomplete) extract from one of my unit tests.

unit_test_example.rb

@driven said:

a 'User Translation' mode for one my plugins

Fredo has worked on a translation tool via webdialog, and you too. Ideally we would be able to re-use existing systems that just need to be installed and avoid re-inventing as much as possible. Before we come to a comclusion or decision, it is important to collect all our experiences with our own efforts or with how professional translation systems work.

For now, we would best concentrate on a requirements analysis or suggestions for functional solutions, and not dive too deep into technical solutions.

@driven said:

Primarily, I believe non-developer 'User Translations' need to be accomplished from within SU itself using at least 2 local WebDialogs and a cloud based index of contextually targeted words and phrases.

So if I understand right, your idea is a kind of "translation suite" installed on the client side (directly in context of SketchUp).
My thought of an online system was that these are readily available, and the possible translator base would be all the SCF members and not limited to those who have the translation plugin installed.

But you have a very important point here:
Translators need to have an idea of the context where a translated string appears.
Traditionally this is often achieved by developer/translator comments, but ideally one could dream of a WYSIWYG editor, where the software's GUI elements have editable text. This might be available in established GUI toolkits/IDEs. But for SketchUp it is complicated because of its API's very diverse and dispersed UI elements (menu, toolbar, tooltips, OpenGL text, status bar, WebDialogs with complicated skp bridge). We are neither GUI framework developers nor IDE developers, so for the beginning I wouldn't see it in scope of what we could achieve.

An online translation management system exposes for each software package a list of translatable strings. Users work through the list of untranslated strings without obligation to "finish" 100% on their own. For each translatable string the system proposes similar strings from the already translated base.
The translation software generates from a completed language (or 70% completed) an output file that can be distributed with the software. A common output file format is .po (GNU gettext).
Usually such translation management systems are fully integrated with package management systems, ie. users receive translations with their software updates.

@rich o brien said:

What needs to happen?

We need to check out how to expose our translatable strings to a translation system, and how to get them out again.

• SCF decides for and installs a translation management system
• we developers would need to agree on a common format. I think the very large majority uses the same format ( "source"="target";) and it should be fairly simple to extend Pootle or another system to read and write these files.
• with agreement of Trimble SketchUp, the system could be fed with SketchUp's translation strings to have good proposals (and to use a consistent vocabulary of technical terms).
• developers upload their translatable strings to SCF, or (*****) SCF extracts them from an uploaded plugin package
• developers include the resulting files in a plugin package, or (*****) SCF packages the translation files automatically into the plugin package, or SCF distributes them as a separate update to users.
• (*****) eventually developers would need to agree on a common folder structure where translation files are located

Requests for translations have come up recently in some plugin topics. I think the idea had already been there some years ago for having a translation repository.

Now with the unified distribution with the plugins store, I am wondering whether SketchUcation could be able to set up an online localization system, and whether there is a demand?

Often those developers of us who make localizable plugins know only a couple of languages on their own. Users who understand also English either don't know about the translatability, or shy the effort of translating for the other users who need a native version (and thus cannot translate on their own).
A translation system could simplify the process and increase translation coverage.

Here are some more online translation tools:
Pootle
Zanata
…

For this topic it would actually be useful to get feedback from end-users, especially those not reading the English forums.

The creation and display of toolbars depends for example on reading the program's configurations (SketchUp allows showing/hiding) etc., so the whole process might differ from one program to another even if they use the same type of toolbars. Also programs might use different totally user interface toolkits.

Great to see it finished! I can't wait to build our railroad with it.
We have a Märklin H0. If we had a bigger one, we could lay rails from the kitchen outside to the terrace and transport dishes, drinks and food. So there's something to plan

Well, the XPS 15 handles it like Windows 8.1 handles it, you have a similar selection for the scaling factor (100% etc.), and Gnome/GTK3 has a stepless slider.

The question is whether the applications you use adhere to the scaling factor. Windows has a huge and diverse application ecosystem with different toolkits, which is at times its strength but leads also to little inconsistencies. Hi-dpi screens are pilot devices, only by using them you create the demand for developers to fix their applications over time. Look at the good ones and have patience, the tendency is that everything can only improve.

Smaller ecosystems can easierly keep with the pace. All my main applications are of the GTK3 stack and they scale pixelperfectly (why I didn't return my Yoga 2), but as soon as I use for example third-party applications of different toolkits or Windows applications (like SketchUp), I depend on how well they do.